CLHS: Issue ISO-COMPATIBILITY Writeup

#

## 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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.