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.