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

The LRM says that `\`" in a macro body yields \" after unrolling.  It
stands to reason that `\ would yield \.  If so, I would expect

   `M2(@@@)

to yield

    uwire \@@@ = 1'b1;

-- Brad 

-----Original Message-----
From: Greg Jaxon [mailto:Jaxon@synopsys.COM] 
Sent: Monday, October 29, 2007 11:02 AM
To: Brad Pierce
Cc: sv-bc@eda-stds.org
Subject: 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.