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

I think that there have been such attempts in many previous discusions.

Is there any controversy regarding those cases that the proposal does
discuss?

Shalom 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Friday, October 26, 2007 3:58 PM
> To: Bresticker, Shalom
> Cc: Coffin, Eric; sv-bc@server.eda-stds.org
> Subject: 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
> 
---------------------------------------------------------------------
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.