#

## Issue SUBSETTING-POSITION Writeup

    Issue:        SUBSETTING-POSITION
    References:   X3J13 committee and sub-committee meetings
    Category:     Policy
    Edit history: 12-DEC-88, Version 1 by Chapman
                  9-JAN-89, Version 2 by Chapman
                  10-JAN-89, Version 3 by Chapman
                  20-FEB-89, Version 4 by Chapman

    Problem Description:

    Should the CL standard be partitioned such that an implementation
    could chose a subset of all the CL facilities to implement and
    still be a conforming implementation?
    What subsets should be specified in the draft standard we submit to
    ANSI?
    What position should we take if someone should propose a subset?

    Subsets might omit syntax, functions, admissable values or arguments
    to functions, or data types. For example, a subset might disallow SPECIAL
    declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
    might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
    to work on proper lists, or might omit complex numbers. Each of these is a
    "subset" in the sense that a subset of correct programs for the "full"
    language would be correct for the "subset" language.

    Subsets can have various levels of "determinability" for programs. The
    issue is: how easy is it to tell whether a program written in the "full"
    language would run in a "subset" implementation?  Except for the
    (non-trivial) issue of macro expansions, some subsets are "lexically"
    determinable, e.g., if a function is omitted, you can tell if the program
    uses it by scanning the program. Some subsets are "dynamically"
    determinable, e.g, a subset might signal an error if the :TEST argument to
    MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
    dynamically determinable, e.g., if the subset implements dynamic extent for
    rest lists, it may be impossible to tell even with run-type checks whether
    the a program written in the "full" language would conform.

    Some "subsets" might be merely restrictive interpretations, e.g., a
    "run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
    BREAK halt the program execution rather than "enter the debugger"; since we
    cannot define what "enter the debugger" means, we might want to define
    explicitly this subset as a reasonable one for embedded systems.

    Proposal (SUBSETTING-POSITION:NONE)

    The draft standard we submit to ANSI contains *no* subsets.
    In the section on "subsetting" it should be mentioned
    that Lisp is a "small" language with a "big" library.

    We are not opposed in principle to one or more subset definitions.

    Rationale:

    We have no well-defined proposals for subset definitions, and didn't have
    the time or energy to pursue their definition, or confidence that we could
    reach convergence on a reasonable definition.

    There are several properties that a subset definition must have to be
    considered: it must be well defined in terms of conformance of code, programs,
    and implementations; all valid programs in the subset must be valid programs in
    the full language; the subset definition should address how it can be
    determined if  a program in the full language is valid in the subset.

    Current Practice:

    Pascal has two levels of conforming implementations -- level 1 contains
    level 0 and conformant arrays. This was a compromise necessary to achieve
    international agreement. The 1981 PL/I was subsetted and the
    results were a range of implementations between the
    subset and the full language; nobody wanted to use the subset so vendors
    were forced to implement the full language eventually anyway.
    Cobol had multiple levels of subsets. However,
    the only two levels that were important were the minimum
    subset and the full language. The middle levels were
    seldom used other than transient points to the full language.
    Fortran was subsetted. It was felt that subsetting encouraged
    vendors to implement Fortran and therefore proliferate its usage,
    but users were quite annoyed that one Fortran was considerably
    different from another.
    The new Fortran language standards committee is
    banning subsetting.
    At one point, there was an ANSI standard for "Minimal Basic".  It was
    too minimal. Later work on ANSI Basic involved a rather different-looking
    language and a number of optional extensions for such things as real-time process control.
    SPARC feels that subsets aren't good for facilitating interchange, but serve the
    purpose of allowing timely implementation of the standard.

    Adoption Cost:

    None.

    Benefits:

    This policy will provide a basis for making decisions in X3J13.

    Conversion Cost:

    None.

    Aesthetics:

    None.

    Discussion:
    Jeff Dalton says:
    "I'd be happier if it were fairly easy for someone reading the standard
    to determine which part was the "library" and which the core language.
    For example, where do we find FUNCALL and APPLY?
    The draft C standard has an explicit division.  Section 3 is
    "Language" and section 4 is "Library".  It may not be necessary
    to go that far for Common Lisp."

    GLS says: "I am in agreement with SUBSETTING-POSITION:NONE."

    Loosemore says: "... even if the standard doesn't define
    any subsets, that is not going to prevent subsets from happening, and
    perhaps the standard ought to define some terminology to describe such
    implementations (even if it's only to say that they can't call
    themselves Common Lisps at all)."

    RPG says: "One point worth making might be that a conforming program that is
    delivered may not also be a conforming implementation."
    Paraphrased:
    A conforming implementation does not have to be present in order to deliver
    a conforming program.
    One could produce a linkable version of an application that would
    include almost no part of the Lisp environment.
    Therefore, subsets are not mandated for this case.

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