Issue ISO-COMPATIBILITY Writeup

Issue:        ISO-COMPATIBILITY

Forum:	      X3J13 Letter Ballot

References:   ISO SC22/WG16 Committee Draft

Category:     CHANGE

Edit history: 16-Jun-93, Version 1 by Pitman

Status:       Proposal ADD-SUBSTRATE passed 8-3 on letter ballot 93-304.


Problem Description:


  The ISO specification for ISLISP contains features which cannot be 

  straightforwardly implemented in ANSI Common Lisp, but that with

  minor changes could be.


Proposal (ISO-COMPATIBILITY:ADD-SUBSTRATE)


  1. Add a new macro:


     DEFINE-SYMBOL-MACRO name form		[Macro]


     Globally defines a symbol macro named <name> which expands 

     to <form>.


  2. Add a new macro:


     LAMBDA lambda-list &body declarations-and-forms    [Macro]


     The form (lambda ...) is shorthand for #'(lambda ...).


Test Case:


  Sample code to better illustrate the issue goes here.


Rationale:


  This makes it possible to implement ISO's ISLISP dialect entirely

  in portable code.


  1. DEFINE-SYMBOL-MACRO can be used to define global lexicals, 

     by having a global lexical be a symbol macro that expands 

     into a reference to a globally allocated cell that is not

     subject to dynamic binding.


     DEFINE-SYMBOL-MACRO can also be used to define the ISLISP

     notion of a compiler constant, which is a variable that

     cannot be assigned but that CAN be bound.  The implementation

     is the same as for global lexicals, except that the expansion

     form is not SETF-able.


  2. A LAMBDA, although conceptually trivial, cannot be defined by 

     users because issue LISP-SYMBOL-REDEFINITION places restrictions

     on users' ability to add definitions to symbols in the CL package.


  Also, each of these features is independently useful in its own right.


  1. DEFINE-SYMBOL-MACRO has been requested by some users.

     For example, see Public Review comment Pitman #10.


     Some users have also requested global lexicals, 

     especially those from the Scheme community.

     For example, see Public Review comment Loosemore #30.


     Some users have also requested ISLISP-style constants,

     especially those from the Eulisp community.

     For example, see Public Review comment Dalton #4.


   2. A LAMBDA macro has been requested by many users,

      especially, but not at all exclusively, those from the

      Scheme and Eulisp communities.

      Issue LAMBDA-FORM previously failed before this committee,

      however at a time when the compatibility issue with other 

      Lisp standards was not as great a concern.  It's appropriate

      that the concept be reconsidered again here in this new light.


Current Practice:


  1. Symbolics Genera provides DEFINE-SYMBOL-MACRO as an 

     implementation-depednent extension.


  2. Symbolics Genera has long provided a LAMBDA macro, which was

     permitted as an extention under CLtL, but not the dpANS.  Users

     were upset when this was not only taken away from them, but they

     were forbidden from creating it anew.  (It's quite a complicated 

     symbol to be shadowing.)


     Most Lisp dialects don't provide a LAMBDA macro since doing so 

     would be a violation of the spec.


Cost to Implementors:


  1. Relatively small.


  2. Very small.  

       (DEFMACRO LAMBDA (&WHOLE FORM &REST BVL-DECLS-AND-BODY)

	  (DECLARE (IGNORE BVL-DECLS-AND-BODY))

	  `#',FORM)


Cost to Users:


  1. None.  (This change is upward compatible.)


  2. Very small.  (Mostly the need to remove any compatibility definition

      they might already have, in spite of warnings that they should not

      have such a thing.)


Cost of Non-Adoption:


  The relation of ANSI CL to ISLISP would be difficult to explain.  Neither is

  a subset of the other, so they would appear as competing dialects and it might

  be a hassle for some vendors to explain off the lack of coordination. 


Benefits:


  If we can say that ANSI CL is capable of implementing ISLISP, 

  then ISLISP becomes a substantially reduced threat in some situations.


Editorial Impact:


  Relatively small.


  1. Changes to the description of how symbol macros are processed.

     A new dictionary entry for the DEFINE-SYMBOL-MACRO macro.


  2. A new dictionary entry for the LAMBDA macro.


Aesthetics:


  1. Having DEFINE-SYMBOL-MACRO as a companion to SYMBOL-MACROLET seems

     to make things simpler to explain, since users often expect there

     to be both definers and binders for things in the environment.


  2. People are mixed on the aesthetics of this:


     - Some people think a LAMBDA form is massively more aesthetic.


     - Some people think LAMBDA is something primitive, not something

	to be layered on as an afterthought with macro technology.


     - Some people think having both (LAMBDA  ...) and #'(LAMBDA ...)

	is extra baggage that look silly.


     - Some people think having both (LAMBDA ...) and #'(LAMBDA ...)

	provides expressional flexibility to two camps who won't be 

	content to settle on a single solution.


     - Some people think having (LAMBDA ...) brings them uncomfortably

	close to having to fight the Lisp1/Lisp2 battle over again.


     - Some people think having (LAMBDA ...) only makes sense in the

	Lisp1 context.


     - Some people think having (LAMBDA ...) ameliorates one of the 

	aggravating problems seen by Lisp1-fans, which is the need to

	write #' in front of things.  It doesn't get rid of all of them,

	but it does get rid of many.


     - Some people think that not having to write #'(LAMBDA ...) may

	lead to further confusion down the road in understanding why the

	car of a form is treated differently than other parts of the form.


     There is not likely to be consensus from an absolute point of view 

     on this.  It is clear that there is no way to optimize aesthetic

     criteria related to LAMBDA in a way that satisfies everyone.


     Pitman thinks this means that people should prefer to add the macro

     since it permits maximal flexibility of style to users at extremely

     low cost to implementors.


Discussion:


  This comment addresses the following Public Review comments:

    Dalton #4

    Pitman #10

    Pitman #32

    Loosemore #30

  Pitman strongly supports this proposal.


  The data for this proposal was generated from an experiment:

  As a test, since the dialects were similar, Pitman implemented an 

  approximate version of ISLISP in Common Lisp.  The exercise took 

  only a few hours to code up.  In a few places, Pitman had to use

  implementation-specific techniques to compensate for missing 

  functionality. The items mentioned in this proposal are the things

  he would have needed in Common Lisp in order not to have needed

  implementation-specific substrate.


  It's arguable that things like QUASIQUOTE, UNQUOTE, and

  UNQUOTE-SPLICING should appear in this proposal as well.  However,

  technically, those can be written straightforwardly in CL, so they

  were omitted for reasons of minimalism in order to improve the

  likelihood of this passing.  However, we might want to seriously

  consider them separately since they did get mentioned in other Public

  Review comments as a compatibility issue for Scheme users.