RE: [sv-ec] Re: Feedback from Freescale on name resolution issues

Hi All,

For reference, Jonathan seems to have been inspired to (7)
by the last paragraph of the intro to section 7.13 (Draft4).
This is the section entitled "Array manipulation methods".

One difference I see is that in the case of arrays,
the syntax uses () for both the iterator_argument as
well as the 'with expression':

array_method_call ::=
    expression . array_method_name { attribute_instance } [ (
iterator_argument ) ]
        [ with ( expression ) ]
   
Here is the pertinent text:
"Array manipulation methods iterate over the array elements, which are
then used to evaluate the expression
specified by the with clause. The iterator_argument optionally specifies
the name of the variable used by
the with expression to designate the element of the array at each
iteration. If it is not specified, the name
item is used by default. The scope for the iterator_argument is the with
expression. Specifying an
iterator_argument without also specifying a with clause shall be
illegal."

It's a bit jarring to see one form of the syntax use { }
and the other use ( ).  Comments?

Also, after reviewing 7.13, I'm not sure what minor conflict
you see in the array usage of with expressions, Jonathan.
Can you please elaborate a bit, maybe with a small example?

I like suggestion (7) the best, since it is consistent
with established precedent in the LRM, and it seems to
handle the original problem.

Thanks,
Doug

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Vreugdenhil, Gordon
Sent: Tuesday, October 23, 2007 7:11 AM
To: Ryan, Ray
Cc: Vreugdenhil, Gordon; Jonathan Bromley; sv-ec@server.eda.org
Subject: Re: [sv-ec] Re: Feedback from Freescale on name resolution
issues

Ray,

I'm not quite sure whether you are suggesting that
    randomize with () { ... }
be needed for the "item." form or whether you wanted to
retain the implicit switch to "item." semantics when "item."
was used.

I'm slightly leaning towards wanting the "()" to be required
to cause the rule switch -- I am a bit concerned about
having to re-examine decisions due to a later implicit change
in the rules due to the simple appearance of "item.".

Gord.



Ryan, Ray wrote:
> I agree with Jonathan and Gord that this must be fixed and agree with
> Gord that there is only a minor (acceptable) compatability issue with
> the 'item' syntax. 
> 
> I'd be OK with [7], although it might be useful to allow the "(thing)"
> to be optional and default to "(item)". 
> 
> - Ray
> 
> 
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org 
>> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Vreugdenhil, Gordon
>> Sent: Tuesday, October 23, 2007 6:49 AM
>> To: Jonathan Bromley
>> Cc: sv-ec@server.eda.org
>> Subject: Re: [sv-ec] Re: Feedback from Freescale on name 
>> resolution issues
>>
>>
>>
>> Jonathan Bromley wrote:
>>> I'm continuing to worry away at this (name binding in inline 
>>> constraints) because I believe we have a fairly important usability 
>>> problem here, and a real opportunity to resolve a good fix.
>> [...]
>>
>>> (7) seems to me to be a useful compromise.  It could also be 
>>> retrofitted to the array-method syntax, allowing users to 
>> work around 
>>> a (much less problematic) name conflict that can exist 
>> there with the 
>>> current "item" syntax.  And it has the advantage that it is a 
>>> completely different syntactic form than the present one, clearly 
>>> flagging the different behaviour.
>> I would be Ok with this syntax although I don't really think 
>> it is necessary.  If "item" is being used as a class member 
>> then "item.item" works and is such a unique special case that 
>> I really don't think that it would be that confusing, 
>> particularly if the LRM addresses it directly.
>> There is the minor backwards compatibility issue but I really 
>> don't think that alone requires us to make the change to (7).
>>
>> In any case, I agree with Jonathan that this really must be 
>> fixed, so I'd certainly support either "item." or the 
>> proposal in (7) above.
>>
>> I also agree that the ".name" form would be far too error 
>> prone and easily misread and I would object to that syntax.
>>
>> Gord
>> --
>> --------------------------------------------------------------------
>> 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.
>>
>>

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


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