CLHS: Issue COMMON-FEATURES Writeup

#

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.