Re: Release 1.6 critical TODO items.

[Rob Browning]

Rob Browning <address@hidden> writes:

> OK, then what do we do about re-reading and syncase?

Perhaps syntax-case is presuming functionality out of gensym that we
don't want to guarantee?

A gensym which produces uninterned symbols works fine for normal macro
expansions.  The only problem arises when you want those same symbols
to survive a write/read cycle without loosing their "uninternedness".
But there's no way to fix that without also breaking gensym's
guarantee that it returns unique symbols.

I checked Common Lisp and there gensym returns uninterned symbols, and
gentemp returns (currently) unique interned symbols.  At least in gcl,
they use a reader syntax #:G101 which causes (AFAICT) the symbol to be
read back in uninterned.  This does guarantee that you can't create an
"eq?" symbol from the reader via '#:G101, but it also means that

  (eval '(eq #:G101 #:G101))

will be false.  i.e. Common Lisp doesn't guarantee the functionality
that syntax-case wants to depend on either.

My current impression is that we should follow the Common Lisp model
and have gensym *always* return uninterned, and either unreadable, or
"readable as uninterned" symbols.

Then we should see about fixing syntax case to not depend on gensym
invariance across the write/read barrier.  I haven't looked closely
yet, but I suspect that with some naming conventions in the code, and
a post pssyntax.pp read processing step, which would patch up all the
symbol refs that need to be eq?, but uninterned, this wouldn't be to
hard, but perhaps someone already more familar with the code can
correct me if I'm wrong.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD