guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release 1.6 critical TODO items.


From: Rob Browning
Subject: Re: Release 1.6 critical TODO items.
Date: Wed, 30 Jan 2002 17:39:02 -0600
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu)

Marius Vollmer <address@hidden> writes:

> Everybody who needs uninterned symbols can then use make-symbol, but
> gensym will not suddenly start to produce unreadable symbols.

I think I may have to politely disagree, or at least express some
concern :>

To my mind it's all about what type of possible breakage we'd rather
inflict on people for 1.6.

If we change gensym to produce uninterned and unreadable symbols for
1.6, we'll make the function behave more the way people IMO are likely
to expect, and we'll allow macros to be written using gensym, which is
at least the norm in the RScheme and Common Lisp worlds (I haven't
checked elsewhere), while the class of errors this change may produce
seem likely to be of the nice catastrophic, easily detected, and
easily fixed variety -- the kind that a good loud warning in the NEWS
should help people avoid.  I also wonder if there are really many
people out there using gensym to get symbols that they expect to write
and then read back in (obviously syntax-case was doing that, but who
else?).

On the other hand, the class of errors that the status quo (i.e. still
interning its results) can produce, at least in the macro expansion
case, seem like they may be context sensitive, hard to reproduce, and
potentially cause problems far away from the call to gensym.  Just the
combination of code you've loaded before a given macro expands will
affect whether or not you might get the value that will be shadowed by
code the macro is wrapping.  (Though in fairness, right now, I noticed
that we're not generating gensyms like 'g0, 'g1, 'g2 anymore, so we're
probably a lot less likely to have the actual problem.)

At the moment it seems to me that we're probably better off just
biting the bullet, documenting the issue well, and migrating directly
to the behavior we eventually want now, accepting the (client-side)
bug that will be easy to identify over the one that may be very hard
to track down.

However, if you disagree, then I'm fine with that, but perhaps we
should at least further obfuscate the symbol names that gensym
produces.  Right now it produces something like %%gensym1.  What about
making it even more awkward like #{\ \ _%%foo}# or something, so it's
*really* unlikely anyone would accidentally use it.  (Though we'll
still need to keep the globally unique counter too -- otherwise macros
that expand other macros might be in trouble...)

-- 
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]