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


Issue SYMBOL-MACROLET-TYPE-DECLARATION Writeup

Issue:              SYMBOL-MACROLET-TYPE-DECLARATION

References: SYMBOL-MACROLET, DECLARE

Related issues: SYMBOL-MACROLET-DECLARE

SYNTACTIC-ENVIRONMENT-ACCESS

Category: CLARIFICATON

Edit history: v1, 13 Feb 1991, Sandra Loosemore

v2, 11 Mar 1991, Sandra Loosemore (new proposal PROBABLY)

Problem description:

Proposal SYMBOL-MACROLET-DECLARE:ALLOW says that a type declaration of

a symbol defined as a symbol-macro "is equivalent to wrapping a THE

expression around the expansion of that symbol". There is disagreement

about whether "equivalence" was intended to mean "semantic equivalence"

or "literal equivalence". In other words, must (or might) the value

returned by MACROEXPAND or MACROEXPAND-1 include a THE form if there

are type declarations that apply to the symbol-macro being expanded?

There are four proposals, YES, NO, MAYBE, and PROBABLY.

Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:YES):

Clarify that the equivalence is literal. If a type declaration

is provided for a name that is bound as a symbol-macro, that type

information must appear in the expansion of the symbol-macro

returned by MACROEXPAND or MACROEXPAND-1 as a THE form wrapped around

the expansion provided in its definition.

Rationale for proposal YES:

If the macroexpansion doesn't include the type information, it can

be lost completely.

Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:NO):

Clarify that the equivalence is only in effect. The macroexpansion

of a symbol-macro returned by MACROEXPAND or MACROEXPAND-1 is exactly

the expansion provided in its definition.

Rationale for proposal NO:

As long as we permit implementations to discard declarations as a

matter of policy, it's unreasonable type declarations on symbol

macros to be collected.

Type declarations about symbol-macros need not be lost during

macroexpansion, since this information is returned by the

VARIABLE-INFORMATION function. A code walker could wrap a THE

form around the expansion returned by MACROEXPAND-1 itself, if

it wished to do so.

Maybe some programs depend on the expansion of a symbol-macro being

exactly the same as what was specified in its definition.

Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:MAYBE):

Clarify that the equivalence may be either literal or only in effect.

The macroexpansion of a symbol-macro returned by MACROEXPAND or

MACROEXPAND-1 might or might not include a THE form wrapped around

the the expansion provided in its definition.

Rationale for proposal MAYBE:

Some implementations might want to do things this way. Other

implementations might not.

Proposal (SYMBOL-MACROLET-TYPE-DECLARATION:PROBABLY):

Clarify that the equivalence is literal. If there is type information

available in the environment in which the expansion occurs, then that

type information must appear in the expansion of the symbol-macro

returned by MACROEXPAND or MACROEXPAND-1 as a THE form wrapped around

the expansion provided in its definition.

Rationale for proposal PROBABLY:

If the macroexpansion doesn't include the type information, it can

be lost completely. However, this proposal makes no requirement that

type declarations actually be collected (but it does imply that

type declarations added by an explicit use of AUGMENT-ENVIRONMENT

will be reflected in the expansions).

Current Practice:

I don't know.

Cost to Implementors:

In an implementation that discards type declarations, probably quite

a bit of work would be involved to support proposal YES. However it

may be that the implementors are doing this work anyway to support

the other syntactic-environment-access proposals.

Cost to Users:

Hard to say. Probably there are few programs that depend on any

particular behavior here.

Cost of non-adoption:

Continuing confusion about how to write a code walker.

Performance impact:

Most of the overhead is in keeping track of type declarations.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Seems to depend on who you talk to.

Discussion:

Kim Barrett supports proposal PROBABLY.

Kent Pitman says:

...unless we're going to force declarations to be enforced, it

isn't reasonable to make this requirement on macroexpansion.

Loosemore supports proposal NO, not only because of this problem,

but because it just seems unnecessarily complicated to force

MACROEXPAND to deal with declarations when there are other mechanisms

for retrieving this information available to code walkers.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.