Issue: GENSYM-NAME-STICKINESS, version 2

[Guy Steele <gls@Think.COM>]

Version 2 proposes to provide access to the counter state.


Additional Comments include:

"... it's ... late to consider things like this ..."
"YAY!!!    This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."

!
Issue:        GENSYM-NAME-STICKINESS
Forum:	      Cleanup
References:   GENSYM (p169)
Category:     CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
	      15-Mar-89, Version 2 by Steele

Problem Description:

  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.

Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):

  Define that if an optional argument is given to GENSYM, it does NOT
  have a side-effect on GENSYM's internal state.

  Define that the function GENSYM-COUNTER takes a non-negative integer n
  and modifies the internal state of GENSYM so that the next symbol
  generated will be number n.  GENSYM-COUNTER returns the old value
  of the counter.

Rationale:

  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.

  Occasionally you want to reset the GENSYM counter so that, for example,
  you can get the compiler to generate the same symbol names again
  (good for comparing results to see what really changed).

Test Case:

  (CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
	      #\G)
  => NIL ;under CLtL
  => T   ;under this proposal

  (string= (symbol-name (progn (gensym-counter 43) (gensym "foo")))
           "foo43") => T

Current Practice:

  Symbolics Cloe and Genera are compatible with CLtL, so this would be an
  incompatible change.

Cost to Implementors:

  Very small.

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.

Benefits:

  Gensyms which appear to convey information through their name would not
  accidentally pop out and cause confusion in places where they oughtn't.

Aesthetics:

  Unnecessary global state changes are hard to reason about. This would 
  be a small simplification.

Discussion:

  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 supported version 1.  In response to a query, he said:
  "... the only part of this I really care about is that the name
  not be sticky.  If you make any reasonable counterproposal that gives
  me that one feature, odds are that I'll support it."

  Steele supports this proposal.