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

The rule is needed for two reasons. The more important one is that you
have to say what happens if the argument is empty. For example, in a
task argument list, it can be an error or it can mean to take the
default, if there is one. In fact, the proposal for 1571 says that if a
macro argument has a default and the actual is empty, then you take the
default. So an empty argument gets special treatment.

The other reason is that white space in macro arguments still gets
special treatment. As Steven pointed out, although the LRM calls macro
arguments 'expressions', they aren't really. See Mantis 1333. So white
space within a macro argument is still preserved, isn't it? (I admit, I
did not try it.) Suppose my macro call is `D(left  right), with two
spaces between 'left' and 'right'. In fact, now I seem to remember that
that is the reason I wanted to put in Mantis 1957 the statement about
white space being stripped off the beginning and end of actial
arguments, to contrast it with the middle. So one might think that if a
macro argument consists only of white space, then it leaves a white
space there. So the Mantis says it does not, it is really empty.

I know the behavior was not obvious for me. I mean that I considered it
as one among several possibilities and I did not know which was correct.
Another possible behavior was that it could have been an error, like in
task calls if there is no default.

Other relevant Manti are 1338, 1339, and 1537.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> Sent: Tuesday, September 11, 2007 6:56 AM
> To: Steven Sharp; sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
> Subject: 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.
> 
---------------------------------------------------------------------
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.