[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: GENSYM-NAME-STICKINESS (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 14 Feb 89 15:11 EST
If someone wants to argue that it's too late to consider things like
this, I won't make serious objection. But I recently battled this
problem yet again and I'm just fed up -- writing up the issue was the
most obvious way I could think of to relieve a little tension. Maybe
enough people will empathize with my feelings on this to help me sneak
it in at the last minute...
References: GENSYM (p169)
Edit history: 14-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
=> NIL ;under CLtL
=> T ;under this proposal
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
Cost to Implementors:
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supports the proposal.