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

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Thu Dec 06 2007 - 12:10:55 PST
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, and is
believed to be clean.
Received on Thu Dec 6 12:11:38 2007

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