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

Mantis 1957, which was just passed, treats whitespace as an empty
argument and replaces it with nothing. But if whitespace is already
removed from actuals, this rule should not be needed.

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Monday, September 10, 2007 7:01 PM
> To: sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
> Subject: RE: [sv-bc] Trimming whitespace from macro actuals
> 
> 
> >From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> 
> >I looked through every occurrence of "white space" and "whitespace"
in
> >Draft 3a, but did not find the following rule --
> >
> >> The LRM says that whitespace at the beginning and end of the
arguments
> >is removed.
> 
> Strange.  I thought I recalled this rule being quoted recently (by
Shalom
> in reference to the proposal for 1571?), but I cannot find it in the
LRM
> or my email.  I remember being slightly surprised by the rule, since
white
> space didn't matter in the past.  Apparently I was hallucinating the
> entire
> thing.
> 
> So now I don't know what happens to white space.  The LRM says that
the
> actuals are "expressions" rather than arbitrary text, which might have
> some bearing on this.  However, I expect that in practice,
implementations
> allow fairly arbitrary text.  So it is hard to argue that leading or
> trailing white space should be removed on the grounds that it is not
part
> of the "expression".
> 
> I think we do have to assume that white space terminating an escaped
> identifier is part of the actual.  It is both part of the arbitrary
text
> of the actual, and if the actual is an expression, it is part of the
> text of that expression.
> 
> >Nevertheless, your analysis of the problem is useful and interesting.
I
> >agree with you that Verilog's \-and-whitespace escape brackets make
the
> >problem more complicated than C had to deal with.
> 
> Based on the current LRM specification of how '' works, I conclude
that
> you cannot use it to paste together escaped identifiers.  The LRM does
> not describe '' as pasting tokens together.  It just acts as a lexical
> token delimiter that goes away after macro expansion.  This allows a
> macro formal to be recognized as a token, but to end up immediately
> adjacent to other text after expansion.  This is similar to the old
trick
> in K&R C code of putting a comment between two tokens in a macro to
glue
> them together.
> 
> So you can't just use escaped identifiers in the actuals and expect
them
> to work like normal identifiers that have the escaped names.  You have
to
> be consider their lexical form and what happens to that during the
> substitution and expansion.
> 
> I conclude that
> 
>   assign `paste(\7@ ,8) = 1'b1;
> 
> expands into
> 
>   assign \7@ 8 = 1'b1;
> 
> and
> 
>   assign `paste(\7@ ,\8@ ) = 1'b1;
> 
> expands into
> 
>   assign \7@ \8@  = 1'b1;
> 
> both of which will produce a syntax error.
> 
> So you cannot write a paste macro that works on escaped identifiers.
> This is annoying, but I guess it isn't a huge deal.
> 
> 
> 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.