Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
tonyms@... (Tony Martínez) writes:
> However, I've found that CMUCL/SBCL evaluate #1=[#1#] to [#:GENSYM]
> when boxes aren't implemented as lists, arrays or structs, since the
> algorithm used is to leave gensym markers where the references appear
> and then resolve the references by descending the data type once the
> objects are read. If boxes are implemented as instances of classes
> (**) which aren't lists, arrays or structs, the gensym is inserted in
> the data, but never resolved. Clisp resolves the references no matter
> what the underlying data structure.
I think this is a bug.
The fix, at least initially, is simple:
From: Tony Martinez <tonyms@te...> - 2003-02-07 17:45:55
> > [...] the algorithm used is to leave gensym markers where the
> > references appear and then resolve the references by descending
> > the data type once the objects are read. If boxes are implemented
> > as instances of classes which aren't lists, arrays or
> > structs, the gensym is inserted in the data, but never
> > resolved. [...]
> I think this is a bug.
> The fix, at least initially, is simple: [...]
> It's probably worth merging this as is, if only so we have a test case
> for future refactoring, but it's possible or maybe even likely that
> the punning of standard-objects as (effectively) INSTANCEs will no
> longer work. Still, this fixes your simple case -- can you say
> whether it fixes your more complex application, too?
Dunno about more complex ("less trivial" :), but I've patched 0.7.12
with circle.diff and it works fine. Thanks very very much!