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