Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        SETF-OPTIONAL-ARGUMENTS
Forum:	      Cleanup
References:   SETF (CLtL pp94-97)
Category:     CLARIFICATION/CHANGE
Edit history: 01-Feb-89, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of SETF is silent on the question of how to treat
  place forms for functions which permit optional arguments. For
  example, it says that you can SETF a GETHASH expression, but it
  doesn't say what that means when the optional argument is provided.

  A consequence of any outcome of this clarification should be to 
  advise users about how they should write SETF methods of their own,
  since enforcing any chosen protocol requires programmer cooperation.

Test Case:

  (DEFVAR *HT* (MAKE-HASH-TABLE))		;Line 1
  (GETHASH 'A *HT*) => NIL, NIL, NIL		;Line 2
  (SETF (GETHASH 'A *HT* 0) 0) => 0		;Line 3
  (GETHASH 'A *HT* 0) => 0, T, A		;Line 4
  (GETHASH 'A *HT*) => ??			;Line 5

Proposal (SETF-OPTIONAL-ARGUMENTS:DISALLOW-OPTIONALS):

  Define that when SETF is called on a place which permits optionals,
  it is an error to specify the optionals.

  This makes line 3 of the test case have "undefined consequences".

Proposal (SETF-OPTIONAL-ARGUMENTS:IGNORE-OPTIONALS):

  Define that when SETF is called on a place which permits optionals,
  the optional arguments are ignored.

  This makes the result on line 5 of the test case be 0, T, A.

Proposal (SETF-OPTIONAL-ARGUMENTS:INVERT-EXACTLY):

  Define that when SETF is called on a place which permits optionals,
  only the effect of that particular pattern of optionals needs be updated.

  This makes the result on line 5 of the test case be NIL, NIL, NIL.

Proposal (SETF-OPTIONAL-ARGUMENTS:EXPLICITLY-VAGUE):

  Define that when SETF is called on a place which permits optionals,
  the implementation is free to either ignore the optional arguments
  or to exactly invert the expression.

  This makes the result on line 5 of the test case be either 
  NIL, NIL, NIL or 0, T, A.

Rationale:

  For that programmers of portable code will know what to expect,
  implementations should either explicitly agree on this, or they
  should explicitly agree to disagree...

  DISALLOW-OPTIONALS avoids what some might see as a questionable
  situation.

  IGNORE-OPTIONALS makes the behavior of later accesses without the
  optional more reliable in some cases. It also eliminates the need
  to guard against an optional creeping in when a macro is 
  constructing a SETF form from other code.
 
  INVERT-EXACTLY permits the implementation to optimize storage usage
  in some cases. It also gives what some feel is a cleaner `conceptual'
  description of the overall intent of SETF.

  EXPLICITLY-VAGUE is a fall-back in case of committee deadlock.

Current Practice:

  Symbolics Genera and Symbolics Cloe implement IGNORE-OPTIONALS.

Cost to Implementors:

  Numerous highly localized changes.

  If a particular implementation has documented its behavior on this point
  and is forced to change, some documentation impact might occur.

Cost to Users:

  The situation is currently vague enough that correct code should probably
  not be relying on the behavior in question. However, in practice, some
  implementation-specific code could be broken, depending on the outcome.

Cost of Non-Adoption:

  A gratuitously vague specification.

Benefits:

  Defining this clearly would allow both for portable programs to know
  what to expect, and some of the possible options would increase the
  space of possible constructs available for use.

Aesthetics:

  Each proposal has an angle on aesthetic appeal which is closely coupled
  with the rationale for choosing it.

Discussion:

  Pitman's feelings on this will differ depending on what turns out to
  be current practice. His preference leans toward IGNORE-OPTIONALS because
  he guesses that's current practice in most implementations, and hence
  offers greatest linguistic stability. If it turns out that implementations
  vary widely in current practice, though, his preference might lean more
  toward INVERT-EXACTLY due to aesthetic appeal.