References: Chapter 1, Working draft of standard
Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY, EXTRA-SYNTAX,
MACRO-AS-FUNCTION, UNSOLCITED-MESSAGES, EXTRA-RETURN-VALUES
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
2-FEB-89, Version 5 by Chapman
24-FEB-89, Version 6 by Chapman (added RPG's comment)
10-MAR-89, Version 7 by Chapman (added discussion)
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Presumably the only thing that defining it as an extension can mean from
CL's point of view is `initially defining' it as an extension. Whether
an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of Common Lisp. For
example, it is common practice to redefine some kinds of system functions
in Genera -- to extend the system in interesting ways, to fix bugs, etc.
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
In places where the standard says that "an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
Same as EXTENSIONS-POSITION:DOCUMENTATION except that
an implementation is required to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.
The standard should contain information about language extensions
since most implementations have extended the language.
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
I favor remaining mute on this topic in the standard.
"I favor EXTENSIONS-POSITION:DOCUMENTATION.
I oppose EXTENSIONS-POSITION:DISABLE because it mandates a
particular development environment feature, but Common Lisp
has avoided saying anything about development environments
since that is an area of extreme controversy.
Gabriel's position of standing mute would be okay with me."