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

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Tue Dec 11 2007 - 14:07:42 PST
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.

 

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

 

My understanding has always been that an unadorned "this" must bind to
the target object (p in the example). In addition, the local:: proposal
would allow users to unambiguously refer to the local object using
local::this. Hence, I would flag functions F() and H() above as errors.
Could you elaborate on how you would treat the above example?

 

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 :-)). I
would propose the following (in which I have removed local:: and the
parenthesis language):

 

The randomize()...with constraint block can also reference local
variables and task and function arguments, eliminating the need for
mirroring a local state as member variables in the object class. The
scope for resolution of variable names referenced in the in a constraint
block , from inner to outer, is begins with the randomize()...with
object class, automatic and local variables, task and function
arguments, class variables, and variables in the enclosing scope; . If a
name fails to resolve within the randomize()...with object class, the
name is resolved normally starting in the scope containing the inline
constraint.   The randomize()...with class is brought into scope at the
innermost nesting level.

 

The language above is almost identical to your proposal - sans the
parenthesis proposal, and one added comma.

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Tuesday, December 11, 2007 10:55 AM
To: Arturo Salz
Cc: SV-EC; Mehdi Mohtashemi; Neil.Korpusik@Sun.com
Subject: Re: 1858 local:: proposal uploaded

 

 

 

Arturo Salz wrote:

> I find the repeating of various rules in your proposal to 

> reduce clarity since it isn't clear that you are saying

> "just do local binding".  Are you Ok with the wording that

> I proposed for that aspect in my proposal?

> 

>  

> 

> *I haven't studied your proposal - only glanced at it. I wrote mine 

> before I saw yours.*

> 

> *I believe you're proposing the parenthesis form to guide name
binding, 

> and I'm not sure there was consensus for that.*

 

 

There wasn't objections raised just some questions about whether

both were needed.  I would definitely like both to be available

since requiring the prefix "local::" throughout an inline

constraint can be quite noisy and in some cases there is more

local context than in-target context.

 

Since there is no semantic issue with both biasings, I don't

see why we couldn't permit both.

 

If you aren't going to oppose it, I'll do the merge, otherwise

I won't merge but keep mine distinct so the question can be

separated.

 

 

I still don't like the longer set of "inner to outer" rules in

the original text and preserved by your proposal.  That description

is just too subject to assumptions that things are different

and I do want it to be crystal clear that there is no

difference.

 

 

 

[...]

 

> *I agree that the rules above do not contradict the earlier
statements. 

> But, I do believe they help summarize things, particularly:*

> 

> * - this.foo   forces foo to bind into the randomize-with object - if 

> foo is not a property of the object, it is an error.*

 

 

But I in fact disagree with that.  If "this.foo" doesn't bind into

the target, "this.foo" is resolved as though it were "local::this.foo".

If the inline constraint is not in a class, such a resolution would

be an error but would otherwise denote the local foo.

 

If you are looking for a way to *force* resolution into the target

object, "local::" already gives you that:

    local::obj.foo

 

> 

> * - local::foo forces foo to bind into the local scope of the call.*

 

Exactly.  But that is already a given since local:: would necessarily

bind to the same thing as the prefix of the inline constraint

declaration.  Restating this as a "rule" makes it sound as though

it was special.

 

> 

> * - local::obj.foo is semantically identical to this.foo (and to the 

> less safe unadorned foo).*

 

I disagree.  If "this.foo" is not resolved in the inline constraint

declaration, it can resolve locally.  Otherwise you introduce

a disconnect between just "foo" and "this.foo" if the calling

context has a "foo".  "local::" is the only way to force things.

 

> *I think that having these there are useful. Perhaps I can change the 

> introductory wording*

> 

> *From:*

> 

> Within the in-line constraint, the following rules apply:

> 

> *to:*

> 

>             Given the earlier rules, the following rules can be
deduced:

 

 

I don't want the word "rules" here at all.  If you insist on having

the list there, I would say,

   "Given these rules, the following behavior is implied:"

 

The list is not a set of rules -- it is a set of behaviors that

follow from the rules.

 

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.
Received on Wed Dec 12 18:58:24 2007

This archive was generated by hypermail 2.1.8 : Wed Dec 12 2007 - 18:59:00 PST