#

## Issue EXTENSIONS-POSITION Writeup

    Issue:        EXTENSIONS-POSITION
    References:   Chapter 1, Working draft of standard
    Category:     Clarification
    Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY, EXTRA-SYNTAX,
    		EXTRA-OPTIONAL-KEYWORD-ARGUMENTS, UNSPECIFIED-DATATYPES,
    		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)

    Problem Description:

    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.

    Proposal (EXTENSIONS-POSITION:DOCUMENTATION)

    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
    correctly.

    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.

    Proposal (EXTENSIONS-POSITION:DISABLE)

    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.

    Rationale:

    The standard should contain information about language extensions
    since most implementations have extended the language.

    Current Practice:

    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.

    Adoption Cost:

    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.

    Benefits:

    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.

    Conversion Cost:

    None.

    Aesthetics:

    None.

    Discussion:
    Masinter says:
    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.

    RPG says:
    I favor remaining mute on this topic in the standard.

    Moon says:
    "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."

Copyright 1996-2005, LispWorks Ltd. All rights reserved.