Re: [sv-bc] Mantis 1571: proposal for macro defaults

 
-----Non-member submission from Greg Jaxon-----
Date: Thu, 16 Aug 2007 16:11:30 -0500

Steven,

   Thanks for giving us a coherent alternative; the system you describe
requires less "stack" space to implement.

   It also solves the question Dave asked about how to supply empty text
as a non-default actual: use a `EMPTY  macro!

   There are some difficult issues with your approach; they're not
fatal, but they require a more rigorous description of macro expansion
than currently exists in the LRM.

  1) When several macro invocations pass as actual arguments of
     another macro, the expansion of the top level cannot be
     understood to introduce new uses of the formal arguments
     to the top-level macro.

     `define TOP(a,b) a + b

      `TOP( `TOP(b,1), `TOP(42,a) )

      expands to:  b + 1 + 42 + a
      not into:    42 + a + 1 + 42 + a
      nor into:    b + 1 + 42 + b + 1

   2) So-called "token gluing" (actually implemented as token-delimiter
      removal) has to be placed into this evaluation sequence
      carefully.  The LRM describes '' only when it appears in "macro
text",
      and shows that it is removed sometime after the formal
substitutions
      for the macro definition in which it appears.  It is probably
already
      true that gluing can produce tokens which will be subject to
further
      macro expansion (but not to any further formal substitution, of
course).
      If it does act on the "literal" text, then it should be able to
      modify expansions latent in such text:

	`define CHAR_1  A
	`define CHAR_2  B
	`define CHAR_3  C
	`define CHAR_12 L
	`define BOT( X, Y, Z )  `" `CHAR_``X``Y``2`CHAR_``X `CHAR_``Z `"

        `BOT( 1, `CHAR_1, 3 )   expands to  " ALA C "

I'm not opposed to Steven's alternative - in fact, the last example
above might be enough to settle the question: for if gluing can change
the literal text of the actual before its macro invocation expands, the
expansion MUST follow the test for the actual being omitted!

Greg

Steven Sharp wrote:
>> From: Greg Jaxon <Greg.Jaxon@synopsys.com>
> 
>> Bresticker, Shalom wrote:
>>>> [What] happens if an argument to the macro is itself a macro that 
>>>> turns into empty text. Does the default apply?
>> Although it seems like having your cake and eating it too, I think 
>> the answer here is effectively "yes".  A macro's arguments must be 
>> fully expanded before they are substituted for their formal
counterparts.
> 
> I disagree.  The LRM does not specify the order in which these would 
> be expanded, and I think there is another order which fits better with

> what the LRM does say.  This would be to substitute the macro actuals 
> literally, and then expand any macro invocations that now appear in 
> the resulting text.  Thus the macro does get expanded, but after the 
> substitution has occurred.
> 
> As I said, I don't think the LRM specifies which of these should
occur.
> However, it does contain the statement "Each actual argument is 
> substituted for the corresponding formal argument literally", which 
> could be interpreted as meaning the exact text, before any macro
expansion.
> 
> There is also text that says "The macro text can contain usages of 
> other text macros.  Such usages shall be substituted after the 
> original macro is substituted, not when it is defined."  This is 
> referring to macros in the macro definition, so it does not directly 
> apply.  However, it does acknowledge that substitution must be applied

> to the macro text after it is expanded.  This pass over the expanded 
> text to expand any further macro invocations would suffice to handle 
> macro invocations in the macro arguments as well.
> 
> Your proposed interpretation would require an additional step to 
> expand the macro actuals before substitution, and no such step is 
> specified in the LRM.  So the simplest interpretation of the LRM text 
> would match
> mine: the outer macro is processed by a literal substitution of the 
> actuals for the formals, and then the expanded text is processed to 
> expand any macro invocations contained in it.
> 
>> In Shalom's proposal, the default is raw text (constrained below*); 
>> it is not an expression that needs evaluating.  However, as text, it 
>> could itself be produced by a macro expansion.  There may be a little

>> room for debate about when to expand macros in the default text, but 
>> I think the precedents here all favor expansion in the context of the

>> macro's call site /before/ the expansion of the macro call itself
begins.
> 
> I think the precedents equally or more strongly favor expansion in the

> context of the macro invocation site /after/ the expansion of the 
> macro invocation itself completes.
> 
> Steven Sharp
> sharp@cadence.com
> 


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.