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:

-------