[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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:

-------


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.