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.