Re: [sv-bc] Trimming whitespace from macro actuals

Shalom,

I am a bit concerned that there hasn't been a serious attempt
yet to come up with a *basis* for arguing about the space
handling cases.  There are important choices regarding
either more text-based, token-based, or other semantically rich
approaches.  Any such choice will have a huge bearing on how and why
we make decisions in certain cases.  The simple base cases are a
starting point for discussion but until we determine the
overall effect, making a particular choice and encoding it
right now in the LRM could in fact do more harm than good
in the long run.

Gord.


Bresticker, Shalom wrote:
> I'm all for deciding on this case, but currently the interactions are 
> undefined not only for this case, but for others as well, and users do 
> not have consistent behavior between tools. The proposal in any case 
> does not de-define an already defined case.
>  
> Shalom
> 
>     ------------------------------------------------------------------------
>     *From:* Coffin, Eric [mailto:eric_coffin@mentor.com]
>     *Sent:* Friday, October 26, 2007 12:35 AM
>     *To:* sv-bc@server.eda-stds.org; Brad Pierce
>     *Cc:* Bresticker, Shalom
>     *Subject:* Re: [sv-bc] Trimming whitespace from macro actuals
> 
>     Ignoring backward compatibility (for the time being) and
>     implementation details, which source text option is equivalent to
>     the expanded macro?  Assume that the text "<space>" represents a
>     single ASCII character (character number 32).
> 
>     `define MACRO( A, B )  `"A``B`"
> 
>     `MACRO( \M<space> , \Q<space> )
> 
>     Option 1)  "\M\Q<space>"
>     Option 2) "\M\Q"
>     Option 3) "\MQ"
>     Option 4) "\MQ<space>"
>     Option 5) "\M<space>\Q<space>"
>     Option 6) "\MQ`"                Note that this is a quote followed
>     by an escaped identifier \MQ`"
> 
>     Undefined interactions exist between escaped identifiers, token
>     pasting (gluing) and the `" macro operation.  Passing something may
>     not be better than nothing in this case.
> 
>     -Eric
> 
>     Bresticker, Shalom wrote:
>>     Even if it's not perfect, let's pass something which is better than
>>     nothing.
>>
>>     Shalom 
>>
>>       
>>>     -----Original Message-----
>>>     From: owner-sv-bc@server.eda.org 
>>>     [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
>>>     Sent: Sunday, October 21, 2007 2:11 PM
>>>     To: sv-bc@server.eda-stds.org
>>>     Subject: RE: [sv-bc] Trimming whitespace from macro actuals
>>>
>>>     This issue, whether and how white space around macro actual 
>>>     arguments is stripped off or preserved, was never resolved in 
>>>     a proposal to clarify the LRM, so I have filed Mantis 2140 
>>>     and the attached proposal.
>>>
>>>     Please review.
>>>
>>>     Thanks,
>>>     Shalom 
>>>
>>>     ---------------------------------------------------------------------
>>>     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.
>>>
>>>
>>>         
>>     ---------------------------------------------------------------------
>>     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.
>>
>>       
> 
> ---------------------------------------------------------------------
> 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.

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