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.