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

From: Alsop, Thomas R <thomas.r.alsop_at_.....>
Date: Thu Dec 06 2007 - 12:23:54 PST
Brad, I think you are making a good point that the escaped identifier
should be interpreted, per your example, as not having any white space.
The example you are using is creating a half token example.  If the
white space wasn't stripped out, yes you wouldn't violate 21.5.1, but
you would compile fail after the text is replaced with the wire
assignment.  IMHO, this white space stripping proposal is the correct
implementation even WRT to your escaped identifier example.  If you have
an escaped identifier as a macro replacement, the end user must be smart
enough to recognize the implications of escaped identifiers, i.e. you
must have white space to terminate it.  I constantly emphasize this in
my classes.  Thus if macros are using escaped identifiers and
_terminating_ with them, the usage of that macro better dang well have
the terminating spaces, or you have screwed yourself. 

 

-Tom

 

________________________________

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

 

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 <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , 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 12:25:06 2007

This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 12:25:16 PST