#

## Issue SETF-METHOD-VS-SETF-METHOD Writeup

    Issue:        SETF-METHOD-VS-SETF-METHOD
    Forum:	      Editorial
    References:   DEFINE-SETF-METHOD (CLtL, p106),
    	      GET-SETF-METHOD (CLtL, p106),
    	      GET-SETF-METHOD-MULTIPLE-VALUE (CLtL, p107),
    	      "setf method" (27.1 Glossary, page 27-27, Draft 8.81)
    Category:     CHANGE
    Edit history: 08-Mar-91, Version 1 by Pitman
    	      15-Mar-91, Version 2 by Pitman (merge much discussion)
    	      08-Apr-91, Version 3 by Pitman
    		(GET-SETF-EXPANDER => GET-SETF-EXPANSION, per X3J13)
    Status:	      X3J13 passed option RENAME-OLD-TERMS on 10-3 vote, March 1991.
    	        (Note that option +ADD-ACCESSOR was not voted upon,
    	         and so it is not in effect.)

    Problem Description:

      The terms "@bold(setf) @italic(method)" and "@italic(setf method)"
      mean two different things.  The former means a CLOS method defined
      using DEFMETHOD, which among other things might be used by SETF.
      The latter means a macro-like entity defined by DEFSETF or
      DEFINE-SETF-METHOD, data about which can be retrieved by
      GET-SETF-METHOD[-MULTIPLE-VALUE].

      Verbal confusion will almost surely result from the similarity of
      these two terms.

      Visual confusion will almost surely result if people don't happen to
      notice the font, or to realize the important distinction which it
      seeks to make.

    Proposal (SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS):

      Rename DEFINE-SETF-METHOD to DEFINE-SETF-EXPANDER.
      Remove GET-SETF-METHOD.
      Rename GET-SETF-METHOD-MULTIPLE-VALUE to GET-SETF-EXPANSION.

      Rename the glossary term "setf method" to "setf expander".
      That is, a "setf expander" is a function which tells how to
      store into a generalized reference.

      Create a glossary term "setf expansion" to refer to the five
      magic values returned by a "setf expander".

      Clarify that the glossary term "setf method" is to be synonymous
      with "SETF method" That is, a "setf method" is a CLOS method
      named (SETF <something>).

      Rationale:

        Avoids massive terminological confusion.

        Simplifies the language by promoting GET-SETF-METHOD-MULITPLE-VALUE,
        the general purpose routine, into active duty and removing its
        simpleton pal GET-SETF-METHOD.

    Proposal (SETF-METHOD-VS-SETF-METHOD:+ADD-ACCESSOR):

      Add a new function:

       SETF-EXPANDER-FUNCTION name &OPTIONAL environment            [Function]

       If <name> has a SETF expander function (defined with DEFSETF or
       DEFINE-SETF-METHOD), and the global functional binding of <name> is
       not lexically shadowed within the <environment>,
       SETF-EXPANDER-FUNCTION returns that function.  Otherwise NIL is
       returned.

       A SETF expander function is a function which accepts two arguments,
       the "place" form and an environment, and returns the five values
       representing the SETF expansion for that "place".

       SETF may be used with SETF-EXPANDER-FUNCTION.  The value must either
       be a SETF expander function or NIL (which removes any existing SETF
       expander function associated with the <name>).  [The consequences of
       supplying an environment other than NIL when using SETF of
       SETF-EXPANDER-FUNCTION are not defined.]

      Rationale:

        This is symmetric with having MACRO-FUNCTION and
        COMPILER-MACRO-FUNCTION.

    Current Practice:

      Presumably no one already does this.

    Cost to Implementors:

      RENAME-OLD-TERMS:  Small.  Trivial renaming of functions.
        Old names can be retained as an extension for compatibility
        if necessary to ease transition.

      +ADD-ACCESSOR:  Probably small.  Implementations have to represent
        this information somehow already, so this just provides access to
        what is already there.

    Cost to Users:

      RENAME-OLD-TERMS:
       Small.  It's clearly incompatible, but hopefully the motivation is strong
       enough that users will realize that the change is needed.  A simple
       find-and-replace operation is likely to fix these, or compatibility names
       can be trivially established locally by users for code that can't easily
       be changed in implementations that don't already provide the compatibility
       support for old names.

      +ADD-ACCESSOR: None.

    Cost of Non-Adoption:

      Risk of a `fonto' in the spec causing major havoc.
      Risk of implementors getting confused.
      Risk of confusing new users.
      Either some places in the spec could be harder to word unambiguously,
       or else glossary terms might have to be chosen which do not match
       function names in the language itself.

    Benefits:

      Much easier to have casual verbal discussions.

    Aesthetics:

      RENAME-OLD-TERMS: Major improvement in aesthetics.

      +ADD-ACCESSOR: Language is slightly more uniform.

    Discussion:

      Pitman supports this proposal but is not fussy about the specific
      term that's used as long as it's not the status quo (`method').

      The terms "strategy", "technique", "macroexpander", "macro expander",
      "expander", and "transformer" were discussed after v1. Eric Benson,
      JonL, Sandra, and Pitman all seemed happy with "expander", so it
      v2 was changed to use that.

      There was also support (from Moon and Sandra) for merging
      GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE back into one,
      so v2 added that as well.

      Sandra asked for SETF-EXPANDER-FUNCTION.

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