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


Issue MACRO-SUBFORMS-TOP-LEVEL-P Writeup

Issue:            MACRO-SUBFORMS-TOP-LEVEL-P

References: EVAL-WHEN, COMPILE-FILE,

all macros defined in the standard

Related issues: EVAL-WHEN-NON-TOP-LEVEL

Category: CLARIFICATION

Edit history: v1, 13 Feb 1991, Sandra Loosemore

v2, 11 Mar 1991, Sandra Loosemore

Problem description:

The compilation model defined by issue EVAL-WHEN-NON-TOP-LEVEL specifies

that expansions of macros inherit "top-level-ness" from the macro call.

This makes sense for user-defined macros, but users have no control

over what the expansions of macros defined in the standard are, since

they're provided by the Lisp implementation. The semantics of a macro

call form can depend on whether or not its subforms appear at top-level

in the expansion, so the standard ought to place some constraints

on what the standard macros can expand into.

Proposal (MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS):

Clarify that no subforms of calls to macros defined in the standard

inherit "top-level-ness" from the macro call unless explicitly stated

otherwise.

Clarify that no macros now in the standard pass on "top-level-ness"

to their subforms.

Clarify that even if a macro is normally treated as a special form by

the file compiler, both its handling as a special form and its normal

macro expansion must still satisfy these constraints.

Clarify that compiler-macro functions must ensure that expansions

have the same semantics regarding inheritance of top-level-ness

as the normal function or macro definition of the form.

Rationale:

It fixes the problem.

Current Practice:

Probably many implementations currently return macro expansions that

violate these rules.

Cost to Implementors:

Implementors will have to examine the definitions of all macros they

provide to make sure that they conform to these rules. Some

"optimizations" currently performed may turn out to be invalid;

for example, (and <form>)

could expand into (let () <form>)

but not (locally <form>)

or (progn <form>)

or <form>

Cost to Users:

Probably none.

Cost of non-adoption:

User programs will behave differently in different implementations.

Performance impact:

Probably small.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

The whole business of "top-level-ness" is kind of ugly.

Discussion:

It doesn't appear that any of the ~90 macros defined in the standard

require special exceptions from the rule. Certainly none of the

binding, conditional, or iteration macros ought to pass "top-level-ness"

through.


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