Rainer Joswig <joswig@lisp.de> wrote:
+---------------
| Mostly I see in the manuals of current Common Lisp systems:
| a) we (try to) do ANSI Common Lisp
| b) here are some places where we don't do ANSI CL
| c) here we say how we implement some ANSI CL
| d) we extend/simplify ANSI CL with the following ...
| e) this is our library
| a), b), and c) is just ANSI CL.
+---------------
The CLHS speaks to this:
http://www.lisp.org/HyperSpec/Body/sec_1-5-1-1.html
1.5.1.1 Required Language Features
http://www.lisp.org/HyperSpec/Body/sec_1-5-1-5.html
1.5.1.5 Conformance Statement
...
If the implementation conforms with some but not all of the
requirements of this standard, then the conformance statement
shall be: ...[prototype]...
Also see this glossary entry:
http://www.lisp.org/HyperSpec/Body/glo_p.html#purports_to_conform
PURPORTS TO CONFORM v. makes a good-faith claim of conformance.
This term expresses intention to conform, regardless of whether
the goal of that intention is realized in practice. For example,
language implementations have been known to have bugs, and while
an implementation of this specification with bugs might not be
a conforming implementation, it can still purport to conform.
This is an important distinction in certain specific cases; e.g.,
see the variable *features*.
And this Variable entry:
http://www.lisp.org/HyperSpec/Body/var_stfeaturesst.html
...
:ansi-cl
If present, indicates that this specification has been
adopted by ANSI as an official standard, and that the
implementation purports to conform.
I would suspect that almost all popular CL implementations
*at least* "purport to conform" to the ANSI Standard.
+---------------
| Now would d) make it a language?
| What could be in d) ?
| 1) language extensions like tail recursion elimination
| 2) added special forms
| 3) new built-in data types (decimal arithmetic)
| 4) parallel computing constructs
+---------------
The CLHS speaks to this:
http://www.lisp.org/HyperSpec/Body/sec_1-5-1-3.html
1.5.1.3 Documentation of Extensions
A conforming implementation shall be accompanied by a document that
separately describes any features accepted by the implementation
that are not specified in this standard, but that do not cause any
ambiguity or contradiction when added to the language standard.
Such extensions shall be described as being ``extensions to Common
Lisp as specified by ANSI <<standard number>>.''
So depending on the exact style of integration with base CL,
all of your "d)1-4" *might* be permissible extensions to CL.
But watch out for the restrictions here:
http://www.lisp.org/HyperSpec/Body/sec_1-6.html
1.6 Language Extensions
...
An implementation can have extensions, provided they do not
alter the behavior of conforming code and provided they are
not explicitly prohibited by this standard.
...
The following list contains specific guidance to implementations
concerning certain types of extensions.
- Extra return values ... [prohibited] ...
- Unsolicited messages ... [prohibited] ...
- Implementation of macros and special forms
Macros and special operators defined in this standard
must not be functions.
+---------------
| d) could also describe a sublanguage. Say a Common Lisp
| without CLOS.
+---------------
The CLHS speaks to this:
http://www.lisp.org/HyperSpec/Body/sec_1-7.html
1.7 Language Subsets
The language described in this standard contains no subsets,
though subsets are not forbidden.
For a language to be considered a subset, it must have
the property that any valid program in that language has
equivalent semantics and will run directly (with no extralingual
pre-processing, and no special compatibility packages) in
any conforming implementation of the full language.
A language that conforms to this requirement shall be
described as being a ``subset of Common Lisp as specified
by ANSI <<standard number>>.''
Note: From time to time I have noodled around with the notion of
defining a subset of CL which meets the constraints of CLHS 1.7
and is still sufficiently rich to be interesting and/or useful
[e.g., for "scripting" or CGI or the like]. It's not as easy as
it might at first appear. Little fiddly bits in one corner of
the language interact in subtle ways with fiddly bits in other
corners of the language.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607