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.