[no subject]

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

REM makes a useful point, I think: a dynamically scoped implementation
can be a "true subset" of Common Lisp as long as the cases where the
diference can be seen are not allowed (or are not used in portable
code).  This could be as simple as requiring Special declarations around
any variable used free.

Enumerating the ways in which one language can be a subset of another is
useful, but I think it's important to keep the definition of "true
subset" in mind: if you're writing code in a true subset of Common Lisp,
your code will run in any full implementation of Common Lisp without
modification.  One can also envision "near subsets" in which the code
has to be modified in order to run in Common Lisp, but in which the
modifications are straightforward and perhaps can be done automatically.

My suggestion to DARPA has been that they should not bless any
particular subset, but that where code from many different systems must
ultimately run together (as in some parts of the Strategic Computing
program) they simply require that the code ultimately produced must run
in any full implementation of Common Lisp.  Researchers would be free to
write in a full Common Lisp, any "true subset", or a "near subset" if
they are willing to periodically do that translation.  They could even
do their research in some very diferent Lisp and then hand-translate the
result, though that is obviously doing it the hard way.  This way we do
not penalize people working in full Common Lisp (that would be
counter-productive to the goal of moving toward Common Lisp as a
standard), while providing the maximum flexibility for people who are
working in other implementations.

The only reason I can see for blessing some particular subset is so that
people working in this subset can trade code among themselves, though
they could not in general run code written in unrestricted Common Lisp,
of which there will be an ever-increasing amount.  A very minimal
"interchange subset" that can easily be implemented on top of PSL,
Interlisp, Franz, and maybe T would be of some value, but only if it is
not TOO much more restricted than the intersection of any one of these
languages with full Common Lisp.  My guess is that whenever a full
Common Lisp appears on any family of machines, people will start using
that and stop using the interchange subset.

-- Scott