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

Gord, I understand what you are saying now.  After reading through your
mail to Brad, I agree with you 100%. So long as the token cannot be
continued outside of the macro, regardless of white space, this answers
Brad's question and corrects my understanding of how escaped identifiers
are treated as well.

I also agree that current methods of macro replacement need a lot of
improvement and think this comment you made is very appropriate:

"I am fairly convinced that any correct and compatible approach will
have to be a hybrid description that very carefully deals with when one
is thinking about "text" versus "tokens""

We just don't have the time or luxury of fully replacing this algorithm
now.

Thanks, -Tom


>-----Original Message-----
>From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>Sent: Thursday, December 06, 2007 1:15 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:
>> 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.