Issue COMMON-FEATURES Writeup

Issue:        COMMON-FEATURES

Forum:	      Cleanup

References:   None

Category:     Addition

Edit history: 01-Mar-91, Version 1 by Pitman

Status:	      For X3J13 consideration


Problem Description:


  The Common Lisp dialect defined by this standard needs a feature which 

  uniquely identifies it in *FEATURES* so that it can be distinguished

  from other similar dialects (e.g., those described in CLtL1 and CLtL2).


Proposal (COMMON-FEATURES:SPECIFY):


  Specify the following meanings for features:


    :CLTL1


      An implementation which purports to support a LISP package that

      implements Common Lisp according to the 1984 specification 

      ``Common Lisp: The Language'' should place this feature on *FEATURES*.

      This feature is -not- precluded by any of the features :CLTL2,

      :X3J13, :DRAFT-ANSI-CL, or :ANSI-CL.


    :CLTL2


      An implementation which purports to support a COMMON-LISP package

      that implements Common Lisp according to Steele's 1990 book, 

      ``Common Lisp: The Language, Second Edition'' (CLtL2) should have place

      feature on *FEATURES*.  This feature -is- precluded by any of the

      features :DRAFT-ANSI-CL or :ANSI-CL.


    :X3J13


      An implementation which purports to support a COMMON-LISP package

      that corresponds to some unpublished working draft, or some mix of

      features that approximates an expected X3J13 Draft should place

      this feature on *FEATURES*.


      If this feature appears, :CLTL2 should not appear unless the

      implementation is compatible with and includes as a subset, the 

      dialect described by CLtL2.


    :DRAFT-ANSI-CL


      If and when this specification has gone out for public review,

      implementations which purport to implement the full draft standard

      should place this keyword on *FEATURES*.


      If subsequent drafts are produced before a final standard, additional

      keywords to identify those drafts will be identified at that time.


      This feature is precluded by :ANSI-CL unless the draft ANSI specification

      and the final ANSI specification are completely compatible.


    :ANSI-CL


      If and when this specification is approved as an ANSI standard,

      implementations which purport to implement that ANSI standard

      should place this keyword on *FEATURES*.


    :COMMON-LISP


      This feature must appear in *FEATURES* for any implementation that

      has one or more of the features :X3J13, :DRAFT-ANSI-CL, or :ANSI-CL.

      This feature might appear in *FEATURES* for any implementation that

      has one or more of the features :CLTL2 and :CLTL1.


Examples:


  #+ANSI-CL FOO     ;Sees FOO only in an ANSI standard Common Lisp.

  #-ANSI-CL FOO     ;Sees FOO only in a Common Lisp which is not an ANSI standard.


  #+DRAFT-ANSI-CL FOO ; Sees FOO only in a DRAFT ANSI standard Common Lisp.

  #+DRAFT-ANSI-CL FOO ; Sees FOO only in a DRAFT ANSI standard Common Lisp.


  #+CLTL1 (LISP:REQUIRE ...) ; Sees the (LISP:REQUIRE ...) 

			     ;only if CLtL1 compatibility support is available.


Rationale:


  Users need this to get a foothold as they try to port between dialects

  in transition.


Current Practice:


  Symbolics Genera does not have any of these features.


Cost to Implementors:


  Very small.


Cost to Users:


  None.


Cost of Non-Adoption:


  Users will have to figure out `more imaginative' ways of determining

  this kind of information which they commonly want to know.  In many

  cases, they will add features with names like these themselves, 

  sometimes according to differing criteria, so that if two applications

  which follow such a strategy are loaded into the same environment, they

  might manage to confuse each other if one adds a feature that it thinks

  is not standard and the other intentionally doesn't add the same feature,

  only to find that it's there anyway.


Benefits:


  See above.


Aesthetics:


  Features lists are not really about aesthetics--they're about survival.

  But nevertheless, giving a standard meaning to terms which name standard

  dialects seems like a plus.


Discussion:


  Pitman supports this proposal, but would consider any other reasonable

  alternative that addressed the same issues in a serious way.