Subject: Re: Common Lisp is not a language
From: (Rob Warnock)
Date: Thu, 19 Apr 2007 21:36:02 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Rainer Joswig  <> 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: Required Language Features 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:
    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:
	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: 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:
    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:
    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 Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607