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

Hi Folks,

In Monday's meeting, Arturo mentioned a technique using "std::randomize() with" 
- would something like the following allow us to unambiguously bind names 
locally when we want to?

class Foo (#type T = int);
   T obj; // member object of opaque type parameter class
   int a;
...
   function bar(input int x);
         // a and x bind locally even though they are expected to appear in T,
         // and we can explicitly refer to members of obj using obj.<whatever>?
	randomize (obj) with {obj.a - x > a - obj.x;};
   endfunction
endclass

--Mike

Gordon Vreugdenhil wrote:
> 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
>>>
>>
>>
> 


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