#

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

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