References: X3J13 committee and sub-committee meetings
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
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
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.
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.
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.
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
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.
This policy will provide a basis for making decisions in X3J13.
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."
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.