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

Alsop, Thomas R wrote:
> Your example Gord does not break the interpretation I gave it, maybe I
> wasn't clear enough.  In your case, the escaped identifier is in the
> macro call not the macro definition.  I was referring to the macro
> definition.  
> 
> So if you did this instead:
> 
>     `define ONE_PLUS(\x ) 1+\x
> 
>     module m;
>        int y , z;
>        initial z = `ONE_PLUS(y);
>     endmodule
> 
> You should compile fail because the \x has any additional white space
> stripped, thus when your `ONE_PLUS call uses y and puts no space after
> "y" the semicolon at the end of that line becomes part of the escaped
> identifier.  Granted, that again violates 21.5.1, but my point is that
> this is not legal and will fail.

I disagree.  The \x token terminates at the macro boundary.  Tokens
never continue onto text outside the expansion.

If that is not your intent, I will vote against these proposals.

In addition, at this point, I will likely reverse my vote on
1338 and 1571 until we come into agreement on all of this.  This
is getting to be completely out of hand in terms of what
various people's expectations and interpretations are and given
all of that, I don't think it is in the best interests of the
standard to have any of this move forward in this PAR.  We will
have some more internal discussions here before I commit to
voting against the other proposals as well, but at this point
my recommendation internally will be to back away from any of
these changes unless we can come up with changes that are not
subject to some of the interpretations that are being suggested.

Gord.

> 
> Correct me if I am wrong:)
> 
> -Tom
> 
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>> Sent: Thursday, December 06, 2007 12:41 PM
>> To: Alsop, Thomas R
>> Cc: Brad Pierce; sv-bc@server.eda.org
>> Subject: Re: [sv-bc] Macro mantis proposals 1397 & 1478
>>
>>
>>
>> Alsop, Thomas R wrote:
>>> 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.
>>
>> I completely disagree with this.  Please see my response to Brad.
>>
>> Requiring such an interpretation would break existing code.
>>
>>    `define ONE_PLUS(x) 1+x
>>
>>    module m;
>>       int \y , z;
>>       initial z = `ONE_PLUS(\y );
>>    endmodule
>>
>> This is legal currently and if your intent is to make this illegal,
>> I am going to oppose the change.
>>
>> Gord.
>>
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.