CLHS: Issue GENSYM-NAME-STICKINESS Writeup

#

## Issue GENSYM-NAME-STICKINESS Writeup

    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 (add GENSYM-COUNTER function)
    	      20-Mar-89, Version 3 by Pitman (make it a variable)

    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:LIKE-TEFLON)

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

      Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
      the gensym counter. That is, the next symbol generated by GENSYM will
      be number n.  The initial value of this variable is not defined, but
      must always be a non-negative integer. This variable may be either
      assigned or bound by users at any time, but always to a non-negative
      integer.

      Deprecate the use of a numeric argument to GENSYM.

    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:

      ;; #1: Test stickiness of name part.
      (CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
    	      #\G)
      => NIL ;under CLtL
      => T   ;under this proposal

      ;; #2: Test stickiness of number part.
      (= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
         6790)
      => T   ;under CLtL
      => NIL ;under this proposal (except when *gensym-counter* happens to align)

      ;; #3: Illustrate use of new variable.
      (STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
               "FOO43")
      => T   ;under this proposal (not meaningful previously)

    Current Practice:

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

    Cost to Implementors:

      Very small.

      If any implementations currently use a more compact representation for
      the internal state of GENSYM than a variable holding a string and a
      separate variable holding an integer, they might be forced to change.
      Even then, the change would proabably still be quite 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.

      Making the gensym counter visible as a variable means that people will
      be able to bind the gensym counter locally when they don't want to affect
      the global counter.

    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 and Steele support LIKE-TEFLON.

Copyright 1996-2001, Xanalys Inc. All rights reserved.