CLHS: Issue MACRO-DECLARATIONS Writeup

#

## Issue MACRO-DECLARATIONS Writeup

    Forum:		Cleanup
    Issue:		MACRO-DECLARATIONS
    References:	Issue SYMBOL-MACROLET-DECLARE
    		Issue DECLARATION-SCOPE
    		Issue DECLARE-TYPE-FREE
    		Issue DEFINE-COMPILER-MACRO
    		Issue DYNAMIC-EXTENT
                    Issue DYNAMIC-EXTENT-FUNCTION
    	        Declarations (CLtL chapter 9)
    Category:	CLARIFICATION
    Edit History:   V1, 26 Oct 1989, Sandra Loosemore
    		V2, 02 Nov 1989, Sandra Loosemore (suggestions from Moon)

    Problem Description:

    Issue SYMBOL-MACROLET-DECLARE defines a meaning for TYPE declarations
    when the lexically visible "binding" of the symbol names a
    symbol-macro.  It also requires SYMBOL-MACRO to signal an error if a
    SPECIAL declaration is provided in the body for a symbol which it
    defines as a symbol-macro.

    What is the meaning of a SPECIAL declaration appearing in some other
    context (such as in a LOCALLY construct), for a symbol for which the
    lexically apparent "binding" is a symbol-macro definition?  How about
    any other declaration which normally applies to a variable or function
    binding (IGNORE, DYNAMIC-EXTENT, FTYPE, INLINE, NOTINLINE) when the
    lexically apparent "binding" is a macro or symbol-macro definition?

    Proposal (MACRO-DECLARATIONS:MAKE-EXPLICIT):

    Clarify that the standard declarations that apply to function or variable
    bindings have the following effects when the binding is a macro or
    symbol-macro:

      SPECIAL
        SYMBOL-MACROLET signals an error if it includes a SPECIAL declaration
        for any symbol that it binds as a symbol-macro.  [Issue
        SYMBOL-MACROLET-DECLARE]  Presumably, this error is of type
        PROGRAM-ERROR and is signalled at compile-time rather than run-time.

        A SPECIAL declaration for a symbol whose lexically visible binding
        is a symbol-macro causes that binding to be shadowed, in the same way
        that a SPECIAL declaration shadows lexical variable bindings.

      TYPE
        A TYPE declaration for a symbol that names a symbol-macro is equivalent
        to wrapping a THE expression around the expansion of that symbol-macro.
        [Issue SYMBOL-MACROLET-DECLARE]  This is meaningful regardless of whether
        the declaration appears in the form that bound the symbol-macro or as a
        free declaration within the scope of the symbol-macro binding.  Multiple
        TYPE declarations applying to a single symbol-macro binding are handled
        in the same way as multiple TYPE declarations that apply to a
        single variable binding.

      FTYPE
        This declaration is not valid when the lexically apparent binding
        is a macro binding rather than a function binding.  (This is because
        FTYPE declares the functional binding of the name to be of a particular
        subtype of FUNCTION, and macros are not FUNCTIONs.)

      IGNORE
        IGNORE declarations for symbol-macro bindings should be treated in
        exactly the same way as IGNORE declarations for variable bindings.
        In other words, such a declaration specifies that the bindings of
        of the specified symbol-macros are never used.

      DYNAMIC-EXTENT
        This declaration is not valid when the lexically apparent binding
        is a symbol-macro or macro binding rather than a variable or
        function binding.

      NOTINLINE
        In the presence of compiler-macro definitions, this declaration
        affects references to macros in exactly the same way that it affects
        references to functions.  When the lexically apparent binding is a
        macro that also has a compiler-macro definition, this declaration can
        be used to indicate to a language processor that the macro (and not the
        compiler-macro) definition should be used.  [Issue DEFINE-COMPILER-MACRO.]
        A NOTINLINE declaration for a macro has otherwise has no effect on
        its expansion.  Implementations are not free to ignore this declaration.

      INLINE
        To parallel treatment of NOTINLINE, in the presence of compiler-macro
        definitions, this declaration affects references to macros in exactly
        the same way that it affects references to functions.  When the lexically
        apparent binding is a macro that also has a compiler-macro definition,
        this declaration can be used to indicate to a language processor that
        the compiler-macro (and not the macro) definition should be used.  An
        INLINE declaration for a macro otherwise has no effect on its expansion.
        Implementations are free to ignore this declaration.

    In those situations where the use of the declaration is not valid, the
    consequences of evaluating or compiling the program are undefined.

    Rationale:

    This proposal is primarily an explicit restatement of things which have
    already been stated in other places, with some obvious interpolations
    added.

    Leaving the consequences undefined permits implementations to signal
    an error, to assign some implementation-specific interpretation to
    the declaration, or simply to ignore the declaration.

    Current Practice:

    Utah Common Lisp implements this proposal.  It currently ignores all
    declarations that apply to function or variable bindings when the
    lexically visible binding is a macro or symbol-macro.  The
    declarations are added to the environment in the normal way but are
    never examined by the interpreter or compiler.  The exception is that
    a SPECIAL declaration will shadow a symbol-macro definition in the
    same way that it will shadow a lexical variable binding.

    Neither HPCL-I nor Lucid CL complain about FTYPE or INLINE/NOTINLINE
    declarations when the lexically visible function "binding" is a macro.
    They are apparently being ignored.  KCL ignores all declarations
    that apply to function bindings (and doesn't yet support symbol-macros).

    Cost to implementors:

    Presumably small.

    Cost to users:

    It seems unlikely that this proposal would be an incompatible change
    that causes many user programs to break, particularly given the
    relative newness of symbol-macros and compiler-macros.

    Benefits:

    More complete specification of the language and less chance for confusion
    to arise later on.

    Aesthetics:

    Some people might be bothered by the asymmetry between the handling of
    TYPE and FTYPE declarations.  Strictly speaking, the special handling for
    TYPE declarations is unnecessary since one could explicitly include the
    THE form in the expansion of the symbol-macro.  Other people probably
    think that the notational convenience outweighs the asymmetry.

    Discussion:
    -------

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