IF-BODY (Version 5)

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

I hope this draft manages to merge the IF-BODY:NO stuff in
a relatively fair way. -kmp

 ``... looks reasonably balanced to me, and represents my
   own opinions adequately.  I see no objection to releasing
   it to the world at large ...''

	-- Guy L. Steele, Jr.
	   author of ``Common Lisp: The Language''

==============================================================================
Issue:        IF-BODY
References:   IF (p115)
Category:     ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman   (IF-BODY:YES)
	       3-Mar-87, Version 2 by Fahlman  (added IF-BODY:NO)
	      17-Apr-87, Version 3 by Masinter (merged v1 and v2)
	      19-Apr-87, Version 4 by Pitman   (misc editing to v3)
	      27-Apr-87, Version 5 by Pitman   (reworked for balance)
Status:       Not for release

Problem Description:

  CLtL defines the meaning of an IF expression only in the case of two or
  three arguments. Some implementations extend the meaning to allow more
  arguments.

  Typically, using the extended IF syntax will not generate a warning in
  environments which support it. Code developed where these features are
  available is not typically discovered to be in error until a port to
  some other implementation is attempted. At that point, which is 
  typically inconveniently late in the development cycle, the developer
  may notice that code either does not compile (generates syntax errors)
  or does not compile correctly (the additional forms are quietly ignored
  and the code generated is not what the writer intended).

  The problem is rightly due to the user, but users typically expect that
  they should be warned about such problems. Unfortunately, however, both
  the Lisp which allows the extended syntax and that which fails to signal
  an error about the invalid syntax are within their rights as currently
  stated.

  This phenomenon is a barrier to Common Lisp's portability goals.

Test Case:
 
  (IF NIL 'THEN 'ELSE 'MORE)

  According to CLtL, this is an error.
  In some implementations, this returns ELSE.
  In some implementations, this returns MORE.
  In some implementations, this signals an error at syntax analysis time.

Notes about Voting:

  Select one of IF-BODY:ILLEGAL, IF-BODY:LEGAL, or IF-BODY:UNCHANGED.

Proposal (IF-BODY:ILLEGAL):

  Restrict IF, making it expressly illegal to supply more than three
  argument forms. Require that implementations signal an error at
  syntax analysis time.

  Rationale:

    As long as some implementations provide this extension while
    others do not, the portability goals of Common Lisp will suffer.
    It is not adequate to encourage implementors to warn about 
    non-standard uses since the only implementations which will
    implement the extension are ones who think it is a good idea to
    use the feature, and people are not inclined to warn about things
    they think are a good idea to use.

    Although some implementations offer extended definitions and
    this would be an incompatible change, the cost of that change
    would be offset by the improvement in code portability.

  Adoption Cost:

    The direct act of making this restriction is trivial, but there
    are nth order effects which may be non-trivial...

    In Symbolics implementations the SCL package contains Symbolics'
    extensions to LISP. Currently, for any symbol LISP:xxx, the
    expression (EQ 'LISP:xxx 'SCL:xxx) => T. This change would force
    as a second order effect a decision about whether to make
    (EQ 'LISP:IF 'SCL:IF) => NIL or to rewrite all code (user and 
    system) using the extended IF.

    Since there are currently no cases where LISP symbols are not
    shared by SCL, a decision to break the sharing would force us
    to do a complicated re-evaluate our position on the nature of
    compatibility between Common Lisp and the extensions we provide.

    The cost of this option is therefore potentially large.

  Conversion Cost:

    Uses of IF in correct Common Lisp code are technically unaffected
    by this change, although it should be clear from the discussion
    of Adoption Cost that viewing things this way may be just a word
    game. In practice, there might be non-trivial effects on 
    code that is not technically `Common Lisp' but which is thought to
    be `Common Lisp compatible.' The importance of this must be weighed
    in context, but should not be discounted altogether.

  Benefits:

    Code portability between certain dialects would be improved.

  Aesthetics:

    The (IF test then else) syntax is neatly symmetric and this
    symmetry should be preserved.

    Some people find the asymmetry of the (IF test then {else}*)
    syntax to be visually confusing.

    IF is supposed to be the simplest conditional form, from which
    all the others are built.

Proposal (IF-BODY:LEGAL):

  Extend IF, making it expressly legal to supply an implicit-PROGN of
  `else' forms using the syntax (IF test then {else}*).

  Rationale:

    As long as some implementations provide this extension while
    others do not, the portability goals of Common Lisp will suffer.
    It is not adequate to encourage implementors to warn about 
    non-standard uses since the only implementations which will
    implement the extension are ones who think it is a good idea to
    use the feature, and people are not inclined to warn about things
    they think are a good idea to use.

    Although some implementations offer extended definitions and
    this would be an incompatible change, the cost of that change
    would be offset by the improvement in code portability.

  Adoption Cost:

    In most implementations, making this syntax legal is a matter of
    a fairly localized change to a finite number of utilities which
    reason about programs (compiler, interpreter, code walkers). No
    changes to code which does not reason about programs would be 
    necessary.

    In some implementations which have incompatible extension 
    strategies, such as keyword-driven facilities, the cost is higher
    because this is an incompatible change. The cost of adoption in
    such cases is hard to estimate; implementors who feel they have
    severe concerns about this should raise those concerns and we'll
    modify this proposal to reflect them.

  Benefits:

    Code portability between certain dialects would be improved.

  Aesthetics:

    The resolution of this controversial programming style issue
    is left to the user rather than being forced by the language
    designer. Those who prefer the symmetry of the (IF test then else)
    syntax are free to use it exclusively without infringing on the
    desires of others to use the extended syntax.

    Some people find the alternatives to (IF test then {else}*) to
    be too visually cumbersome.

    Although IF was supposed to be a simple conditional form, usage
    patterns suggest that this is not uppermost in many users' minds.
    Experience in user communities where extended IF is available 
    show that few users object to its presence; most are happy for
    the syntactic flexibility it provides.

Proposal (IF-BODY:UNCHANGED):

  Leave IF as currently specified in CLtL.

  Implicit in this proposal is that it would be valid for any
  implementation to extend IF as long as such an extension was done
  in a way that was `upward compatible' with Common Lisp.

  Rationale:

    The other two proposals are inadequately motivated.

    Since some implementations already support extensions, it would
    be disruptive to those implementations to require that the
    extensions be removed. Not altering the current definition is
    maximally conservative with regard to existing code.

  Adoption Cost:

    Making this syntax legal is trivial since everyone is
    presumably already compatible with the existing standard.

    Implicit in the acceptance of this proposal, however is the
    incremental cost of late debugging of programs which are in error
    but for which no diagnostic has been generated because we have 
    not required such a diagnostic.

  Benefits:

    The current state of the world would be unaffected.

  Aesthetics:

    The (IF test then else) syntax is neatly symmetric and this
    symmetry should be preserved.

    Some people find the asymmetry of the (IF test then {else}*)
    syntax to be visually confusing.

    IF is supposed to be the simplest conditional form, from which
    all the others are built.

Current Practice:

  Some implementations already provide this feature.

  A few implementations provide alternate keyword-driven extensions
  that are incompatible with the IF-BODY:LEGAL extension.
   
  Some implementations signal an error if other than two or three
  arguments are passed.

  Some implementations quietly ignore additional arguments to IF (making
  it hard to detect errors in code that was developed on systems with
  the extended syntax).

Discussion:

  MACSYMA ran into this problem.

  KMP supports IF-BODY:LEGAL.
  Steele and Fahlman support IF-BODY:UNCHANGED.
  Moon has no strong opinion.

  Fahlman expressed strong concern about the potential precedent which 
  could be set by using compatibility concerns as a lever to introduce
  all kinds of unwanted idiosyncratic extensions present in only one
  implementation and no other.

  Moon suggested that the mere fact that some people like an extension
  is not sufficient reason to put it into the language, but is
  sufficient reason to -discuss- putting it into the language.

  Steele notes that one of the reasons for including IF in the language
  is to have a simple primitive that can easily be recognized, by people
  and by program-walkers alike, as being the simplest conditional and
  not having implicit PROGNs as do WHEN, UNLESS, and COND.

  KMP thinks the language is already so cluttered that worrying about
  such a tiny change to IF is unwarranted. He thinks that if the only
  concern was primitive simplicity, we should just redefine the layer
  at which simplicity is achieved by letting LISP:IF be a macro that
  expands into PRIMITIVE:IF which has simpler semantics but which no
  one has to be stuck programming with (if they don't want to). You
  could argue that users should make their own JDOE:IF macro that has
  this extension, but since this is likely to be a common extension, it's
  our place to consider it for adoption as part of the standard.