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

Mike,

I don't believe there is any direct manner of resolving this
in the LRM currently.

I've raised this direct issue in the past -- here is the
prototypical example that I've used:

    function automatic void f (int x);
        some_obj.randomize with (y < x);
    endfunction

I've suggested that we allow a new syntactic form
for this:
    some_obj.randomize with (y) (x < y);
which I read as "randomize with y in obj such that x < y"

So "y" would bind following the special "into the object first"
rules and "x" would bind using the normal rules.  The current
syntax would continue to follow the special resolution rules
that are currently required.


There are other potential solutions in this space but they
would impact general name resolution rules.  It seems that
the local syntactic solution that I have proposed would
work well and would almost certainly compose well with other
independent issues in name resolution.

Gord.



Michael Burns wrote:
> 
> Hi again folks,
> 
> It turns out that there is a case where it is not possible to 
> disambiguate the simple name reference in a "randomize() with" - when 
> the lexical scope contains locals/automatics, there's no way to 
> explicitly say that you intend a name to bind to the local rather than 
> into the opaque randomized object.
> 
> This clearly seems dangerous, and I can't see any way in the current 
> standard to protect ourselves from it without resorting to annoying, 
> fragile naming conventions. Does anyone have a good solution? If there 
> isn't a good way to deal with this using what we have, I'd like to see a 
> fix added in the 2008 standard.
> 
> Thanks,
> --Mike
> 
> Michael Burns wrote:
>>
>> Hi sv-ec and sv-ac,
>>
>> Here's some feedback from Freescale on the name resolution issues w/ 
>> opaque types raised in the face-to-face meeting a few weeks ago. I 
>> believe the vendors were asking for some direction from users - I hope 
>> this helps. We address three areas - "randomize() with" on opaque type 
>> objects, deriving from opaque type classes, and the overall issue of 
>> static vs. dynamic typing.
>>
>> For constraints in "randomize() with" on opaque type objects, we feel 
>> that the binding rules on simple names are scary enough that we just 
>> won't use them - we'd rather use our internal coding standards to 
>> mandate explicit disambiguation either into the opaque type object 
>> being randomized or into the enclosing lexical scope. As long as the 
>> LRM provides for disambiguation, we don't see the need to make any LRM 
>> changes to address this issue.
>>
>> We aren't as interested in deriving from opaque types - not because it 
>> isn't useful, but simply because we don't see it being implemented 
>> widely enough soon enough to be on our radar yet. We would use this 
>> feature if it were available, but we aren't pushing it. We would not 
>> want to see a delay in the standard to straighten it out, but would 
>> expect to see it working properly in the next revision (if it isn't 
>> working already today, which isn't yet clear). We would expect the 
>> name resolution to work as it appears to today - preferentially into 
>> the opaque base class. We would avoid unexpected name binding by using 
>> internal coding standards to prevent the use of simple names in the 
>> enclosing lexical scope that are also expected to be present in the 
>> opaque base class.
>>
>> Overall, we are interested in the robustness of static typing and 
>> would like to know more about Mentor's proposals for "specs" for type 
>> parameters, but again, we aren't in favor of delaying the standard to 
>> get it included this time around.
>>
>> --Mike Burns
>>   Freescale
>>
> 
> 

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