[sv-ec] Re: 1858 local:: proposal uploaded

Arturo Salz wrote:
> Gord,
> 
>  
> 
> We seem to be discussing three issues:
> 
>  
> 
> 1) Problems with the existing "inner to outer" language
> 
> 2) The pass-by-name proposal to force object binding
> 
> 3) The local:: proposal
> 
>  
> 
> I think we should keep these separate. Regarding the consensus issue for 
> both mechanisms, that is what I meant. I do not have a strong objection 
> to having both mechanisms, but I do have a preference for only one 
> disambiguating mechanism – which I believe should be local::. That is my 
> opinion, but I’d be happy to put it aside and reach consensus if users 
> express a preference for both mechanisms.


We have users (not on the committees) that have told us that
they would like the "bias change" that I have in my parenthesized
form versus having to duplicate "local::".


> At another level, I do believe we have a fundamental disagreement on how 
> to resolve implicit variable names such as this (and possibly super). 
> You are suggesting that an expression such as this.foo can resolve to 
> either the target object (the object being randomized) or the local 
> object. This seems to violate you own principle of avoiding desperate 
> binding and stop the upward resolution once a variable is found to match 
> the first prefix. 

Well, the "this" binding is related to the special rules for
inline constraints to begin with.

What I really do not like is having "this.foo" and "foo" mean
the same thing outside the inline constraint and having
them mean different things inside the inline constraint.

The normal rule within a non-static class method is that
if "foo" binds to a class member then "this.foo" is fine.
To break that equivalence within an inline constraint
is asking for confusion.  The "desperate binding" appeal
doesn't apply in quite the same manner since "this" has
special semantics in any case.


 > Not only that, but the mechanism you propose seems
> allow binding "this" to two different objects in the same constraint 
> block, For example:  
> 
>   class A;
>      rand int x;
>   endclass
> 
>   class B;
>      int y;
>      A   p;
> 
>    function int F();
>         F = p.randomize() with { this.x < this.y; };
>      endfunction
> 
>      function int G();
>         F = p.randomize() with { this.x < local::y; };
>      endfunction
> 
>      function int H();
>         F = p.randomize() with { p.x < this.y; };
>      endfunction
>  endclass
>
> Are you suggesting that all the above code work?

Yes (other than the use of "F" in each assignment).

And this parallels:
    p.randomize() with { x < y; };
    p.randomize() with { this.x < this.y; };

In each case "this.<member>" and "<member>" bind consistently.
Under your rules they would not -- the second would be
valid but not the first since "y" wasn't in "p".  I don't
like that member reference inconsistency and think that will
be much more confusing.

Now if I have my "()" syntax, I'd be happier since then at
least I have an easier way to have the consistency that
I am after -- if you use the "()" form you get only one "this".

> As for issue (1), the existing “inner to outer” verbiage, I agree that 
> this can be simplified, and I like what you have done (mostly J). 

I'm fine with your variant of the language.

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.