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

 Mike,

In your example, you are not using std::randomize(). You are calling the
randomize method of the class Foo (ie this.randomize(obj)...). So the
reference to 'x' in the with clause will resolve to the local 'x'
parameter only if there is not an 'x' declared in class Foo.

You would need to call:
	std::randomize(obj) with {obj.a - x > a - obj.x};

When std::randomize(obj) is called, there is no parent object class, so
the scope for name resolution starts with automatic and local variables.

Additional note: Using std::randomize also changes the random stability
(17.14). The std::randomize method uses the RNG (Random Number
Generator) of the executing  thread. The randomize method of a class
uses the RNG of the class instance.

The following all randomize 'obj'

1)	obj.randomize() with { ... }

Here the scope for name resolution is first 'obj', then automatic and
local variables, ... . The randomization uses the RNG of the class
instance 'obj'.

2)	par.randomize(obj) with { ... }

Here 'obj' must be a property of 'par'. In addition to the 'with'
clause, all the active constraints in 'par' are included. The scope for
name resolution is first 'par', then automatic and local variables, ...
.  The randomization uses the RNG of the class instance 'par'.

3)	std::randomize(obj) with { ... }

Here the scope for name resolution starts with the automatic and local
variables (there is no class scope). The randomization uses the RNG of
the executing thread.


- Ray


> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Michael Burns
> Sent: Thursday, October 18, 2007 9:35 AM
> To: Vreugdenhil, Gordon
> Cc: sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: [sv-ec] 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.
> 
> 

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