Re: [sv-ec]E-mail Vote: Closes 12am PST December 15 2007

Arturo Salz wrote:
[...]
> I still do not understand what you mean by your first point. I don't 
> consider "this" to be the context of the method, but an implicitly 
> defined variable within non-static methods that, upon entry to the 
> method call, happens to be initialized with the value of the object 
> handle making the call. In this vain, I believe that "this" ought to be 
> treated like other variables, hence, it should resolve to one (and only one) 
> object in a particular context. Thus, I don't understand what you mean when 
> you say that I *require* the "this" to NOT be considered the context of 
> the calling method.

(callee in the folllowing is the randomize...with object)

You are considering the "randomize" call to be in the callee and the
inline constraint to be essentially an "extension" of the callee.

But the constraint isn't *just* an extension of the callee.  It also
occurs in the context of the caller -- that is the entire point
of having the rules here to being with.  The rules explain how
BOTH contexts interact with the constraint block.

I don't disagree with "this.x" resolving into the callee's context;
what I do object to is that you say:
     Names qualified by this (i.e., this.a) shall bind to the randomize()...with object class.
                                            ^^^^^^^^^^^^^

That means that it is an error if "this.x" isn't found and could
be found in the caller's context.  This is completely different
from the way in which "x" is resolved.

Obviously all of this is only an issue when the inline constraint
occurs in the context of a class method but in that case there
are in fact two contexts for "this" -- the callee AND the
caller.


 > I believe I do require that precisely - unless modified
> by "local::" in which the context of "this" (along with all other identifiers 
> switches to the local context. At any rate, it seems that this is a discussion 
> of the *current* LRM semantics, and not necessarily a part of the "local::"
> proposal. Incidentally, use of local:: seems not to have any such issues.


Again - you are making that assumption explicit in the proposal.
I disagree with your implicit assumption, do not agree that the
LRM implies that behavior, and object to making that assumption
explicit.


> I now understand that your main objections are related to the proposed 
> change to the grammar. Strictly speaking, you are correct, but I'm sure 
> we can come up with the correct BNF rules if we agree on the semantics. I 
> would propose we first try to close on the intended semantics and then fix 
> the BNF accordingly. I believe neither of us  has the time now to rummage 
> through the grammar to determine how to fix either of our proposals.

I don't believe my proposal has any grammar issues since I don't
have to deal with the various forms of names.


I think the grammar side is resolvable, although I am a bit concerned
about various forms of name collisions between packages, types, etc.
"local::" doesn't really impact those concerns (I don't think) so as long
as the intent is to not be restrictive by way of the grammar, I can
accept deferring that part.




> Barring the grammar issue, I believe we have agreement on almost all 
> issues. There is, of course, the "this" issue, but, as I said before, 
> that is unrelated to the "local::" proposal. At the very least, identifiers 
> qualified by "local::" represent no semantic issues for either of us, or 
> none that I've been able to ascertain.


No, and I have never objected to the originally discussed intent
(which didn't include the "this" issue) nor do I have any problem
with having the originally discussed "local::" aspects being
approved.  Your underlying assumption that you are making explicit
is where I have my deepest objection.




> Finally, I'd like to propose a syntactic change to your proposal that may 
> bring both proposals inline (no pun intended). Having read other people's 
> comments, it seems that one of the more salient objections is the argument 
> list itself, and allow passing any type of names (types, properties, methods) 
> including perhaps names that are not used within the constrain block (or even 
> declared elsewhere) in order to force those names to be looked up in the target 
> class. It seems to me that the most important effect you are want is the "bias 
> change". In fact, you only provided an example with an empty argument list. If 
> I've interpreted your concern correctly, then why not drop the argument list 
> altogether and use:
> 
> 	obj.randomize() with local::{ constraint-block }


Although I only used the empty list in the example in my
proposal, part of the intent was not only the change in
bias but the ability to selectively bias for a concise
form where you don't *expect* any conflicts but want to
protect yourself from later changes.

Your "local::" solves the biasing but would end up causing
ugliness on the inside of the constraint-block in that
"natural" references would be valid any longer.

Here is an example of why I want the selectivity.

Assume you currently have:
      class C;
          int my_value;
          some_class some_obj;
          function void f ();
               some_obj.randomize() with { x < my_value };
          endfunction
      endclass

To protect yourself from change in "some_class", with
your proposal, you would have to write the constraint
as either:
      some_obj.randomize() with { x < local::my_value };
or
      some_obj.randomize() with local::{ some_obj.x < my_value };


In both cases you MUST touch the existing constraint
expressions to end up with safe code.


With my proposal you only need to know the name(s) that you
are referring to in the other class, you DO NOT have to
touch the internals of the assertion expression at all:

      some_obj.randomize() with (x) { x < my_value };

This is much, much less intrusive in real existing
code and works in the presence of macro expanded
expressions that may be used in other contexts.  The
existing proposal (even with the "local:{...}" variant
does not since the expression must be modified.


If all we can reach consensus on is the "local::{...}"
form, I'll live with it, but I think that is still very
limiting and is doing disservice to the actual usefulness
of the constructs in moving forward with simple changes
for ensuring safety in legacy (and/or) new code.

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.