Re: [sv-bc] Trimming whitespace from macro actuals

Brad Pierce wrote:
> Is the following legal?
> 
>    `define M(anything) uwire `\anything = 1'b1;
>    `M2(@@@)

Obviously, your `define lines are properly formed, so the question is
how to write the expansion of your macro calll, and whether the result
has any use in a SystemVerilog statement.

Here the escaped identifier and the macro formal are nominally identical.
We've claimed that they are interchangeable for most purposes.  That either
applies in this case, or it doesn't - and the two expansions that we might
see are therefore:

   (macros of SV token stream)      `@@@= 1'b1;
   (macros of  C token stream)      `\@@@ = 1'b1;

Have I missed something that makes the leading "`" significant in the macro definition?

> How about the following?
> 
>    `define M2(anything) uwire `\anything= 1'b1;
>    `M2(@@@ )

I just realized that I want my windows manager to have a GUI for "mark and diff" ;-)

Here you've botched the SV token stream so it no longer refers to the formal, there
are still two candidate expansions:

   (macros of SV tokens)      `\anything= 1'b1;
   (macros of  C tokens)      `\@@@ = 1'b1;

-----------------------------------------------------

SV's preprocessor departed from the C conventions so
long ago, there's no point in mimicking it /hic et nunc/.

The philosophy that we must "define" every iota of the
SV preprocessor is a burdensome, and rather new idea.
So far, the LRM has stated vague claims that are generally
true, and written vanilla examples that do not test the
boundaries too well.  In short it has "documented" what
common grounds can be found, not prescribed a universal
solution.  Is that a wise course?  I think it leads to
teaching only the most tame uses of this feature, and
not leaning on macros as a route to custom lexical trickery.

If the committee fails to specify a swiss army preprocessor
for SV, will the preprocessing marketplace diverge any more than
if we try weakly playing catch up with C preprocessing
features?   Or is HDL becoming a back-end language for far
more advanced applications that can easily roll their own
text-expansion conventions to suit the application's natural
needs?  Shalom is studying Perl, he says.  There are SO MANY
excellent text manipulation systems - is it IEEE-1800's job
to add to that variety?

Greg

>  
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Sunday, October 28, 2007 2:33 AM
> To: Steven Sharp; sv-bc@eda-stds.org
> Subject: RE: [sv-bc] Trimming whitespace from macro actuals
> 
> Hi, 
> 
>> So we should be careful that we don't define something until we are 
>> sure what we ultimately want to define.
> 
> So far, I have not heard anyone claim that the general rules I proposed
> are wrong, i.e., 
> 
> 1. Normal actual arguments have leading and trailing white space
> stripped off.
> 2. Exception: an escaped identifier at the end of an actual argument
> should keep a white space.
> 
> That takes care of the simple case of escaped identifiers, not involving
> ``.
> Example:
> 
> `define D(a,b) a+b
> 
> `D(\coco , puffs)
> 
> should give you 
> 
> \coco +puffs
> 
> and not
> 
> \coco+puffs
> 
> There is a special case involving escaped identifiers around ``. That
> could be added subsequently as a special case which is really a question
> of how `` works. I don't see that it makes the general rules wrong.
> While it may be clear to everyone that white space is stripped off
> normal arguments, the behavior regarding escaped identifiers has not
> been universal, and therefore even the simple example I wrote above does
> not work in all tools (so I understood).
> 
> If we will manage to specify a desirable behavior for the special cases
> before the deadline, great. That can be addition or a revision of the
> general rules. But let's at least the general rules passed, so that at
> least the simple cases will be guaranteed to work consistently in all
> tools.
> 
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution by
> others is strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
> 
> --
> 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.