Re: [sv-bc] Macro mantis proposals 1397 & 1478

From: Coffin, Eric <eric_coffin_at_.....>
Date: Thu Dec 06 2007 - 13:03:23 PST

Brad,

I don't think that it is the clear implication.   Perhaps if we assumed that all macro expansions must result in a character-for-character transformation that produces textual output, then we might conclude it is the clear implication.

If a macro expansion produces text that when juxtaposed would be interpreted as a different token (which I don't think should happen) then why would we have the token-pasting operator?  It seems to me that the token pasting operator could be replaced with yet another macro expansion.  This would make the following:

`define NoTickTick(a) a
if ( b `NoTickTick(=)`NoTickTick(=) 0)

equivalent to:

if (b == 0)

-Eric


Brad Pierce wrote:

Yet, that's the clear implication of stripping the whitespace from the reasonable macro text in my example.  I don't like the outcome either, but my example shows what the proposal would enable.  My macro uses an escaped identifier, the proposal strips off the terminating whitespace, making it no longer terminated.

 

-- Brad

---

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Coffin, Eric
Sent: Thursday, December 06, 2007 10:07 AM
To: Bresticker, Shalom
Cc: Brad Pierce; sv-bc@eda.org
Subject: Re: [sv-bc] Macro mantis proposals 1397 & 1478

I agree with Shalom that a single token cannot be cobbled together from text that is partially in a macro expansion and partially outside of the same macro expansion.  As Shalom stated the LRM is fairly clear on this in section 21.5.1.

-Eric


Bresticker, Shalom wrote:

You don't agree that joining the macro text with what comes after it
would turn the macro text into half a token?

Shalom 

  

-----Original Message-----
From: owner-sv-bc@server.eda.org 
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
Sent: Thursday, December 06, 2007 6:19 PM
To: sv-bc@server.eda.org
Subject: RE: [sv-bc] Macro mantis proposals 1397 & 1478

No, I don't agree.  My macro text ended in an escaped 
identifier.  The proposal would strip off its trailing 
whitespace.  In any case, the example is a natural one for an 
implementer to think of, so the LRM really ought to be clear 
on the point, if only by giving an example.

-- Brad 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
Behalf Of Bresticker, Shalom
Sent: Thursday, December 06, 2007 2:31 AM
To: Brad Pierce; sv-bc@eda.org
Subject: RE: [sv-bc] Macro mantis proposals 1397 & 1478

Brad,

1. It is true that 1339 is formally being revoted. However, 
there was informal oral agreement on the last revision of the 
proposal at the most recent meeting.

2. Your example probably should not work because of the rule 
that a macro text may not begin or end in the middle of a 
token. The precise LRM text in 21.5 is

"The text specified for macro text shall not be split across 
the following lexical tokens:
- Comments
- Numbers
- String literals
- Identifiers
- Keywords
- Operators" 

Do you agree?

Thanks,
Shalom


    

-----Original Message-----
From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
Sent: Thursday, December 06, 2007 4:30 AM
To: sv-bc@server.eda.org
Subject: RE: [sv-bc] Macro mantis proposals 1397 & 1478

      

Mantis 1339 has been approved which adds the last sentence below:
        

Mantis 1339 is still being considered by the current e-mail vote.  
Also, I added the following bugnote to it

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

It would be nice to see an example of what this proposal means for 
macro texts that end with escaped identifiers. For example, I think 
the following would be legal Verilog under this proposal

   `define MAC(ignored) \!@#
   wire `MAC(ignored)%^&* = 1'b1;
   wire w = \!@#%^&* ;

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

-- Brad

--
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.



--
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.
--
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. Received on Thu Dec 6 13:03:46 2007