CLHS: Issue MACRO-SUBFORMS-TOP-LEVEL-P Writeup

#

## 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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.