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

Gord,

First, let me assure you that I had no intention of insulting you in any way. I'm sorry if my comments offended you. My point was strictly to the proposal and not personal - I apologize for the poor choice of words. 

Now let me address the technical issues we seem to be debating.

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

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.

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.

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 }

That, is by using local:: (or perhaps just local with no ::) you specify the bias change you're after. All identifiers within the inline constraint are looked up strictly in the local context (not the target object class). In a may, moving the "local::" outside the constraint block is equivalent to qualifying all identifiers with local::. The only thing that this may complicate is refer to types in the local object, but I don't see a big problem with this since users can then choose whatever bias works best for their needs.

	Arturo

 
-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, December 14, 2007 10:41 AM
To: Arturo Salz
Cc: Mehdi Mohtashemi; Clifford E. Cummings; Rich, Dave; Francoise Martinolle; Neil.Korpusik@Sun.COM; Ryan, Ray; Steven Sharp; stuart@sutherland-hdl.com; Heath Chambers; mills@lcdm-eng.com; Mark Hartoog; Mike Mintz; David Scott; Michael Burns; sv-ec@eda.org; Jonathan Bromley; Geoffrey.Coram
Subject: Re: [sv-ec]E-mail Vote: Closes 12am PST December 15 2007



Arturo Salz wrote:
>  
> 
> No on Arturo's 1858 proposal (local.pdf).  Reasons:
> 
>    1) I object to the special handling of "this.x" and the fact
>       that "this.x" and "x" resolve differently if "x" is in
>       a local class context but not the randomize object context.
> 
>  
> 
> *I don't know what you mean by this statement and I don't see how it is 
> related to the local:: proposal.*
> 
> *Note that "this.x" and "x" do resolve differently in a local class 
> context (i.e., when x is not a class property but exists in $unit).*


The point is that "this" is NOT a structure or element reference -- it
is the context of the method.  You are magically jumping into a non-method
context (the inline constraint) and expecting that to be treated
as though it were a method context (the only context in which "this"
is valid).  Worse, you then *require* the "this" to NOT be considered
as the context of the calling method.

That inconsistency and abuse of "this" is not Ok.


>    2) The change does not permit "local::this.x"
> 
> *            This is untrue. Where is this disallowed?*

In the grammar.  "this" is not an identifier and has separate
rules in the BNF.  Same with super and this.super.

>    3) "super" and "this" are not symmetric in the proposal
> 
> *            This is untrue. Where does the proposal treat super and 
> this asymmetrically.*

The special rule for "super." is not stated (i.e.that it *must*
bind to the target).  As with "this" I object to that interpretation
but in any case you didn't state it and it is not implied by
any existing text.


>    4) "local::" needs to be permitted in front of a class scope
> 
>       Identifier
> 
> *            It is permitted. I don't see where this is disallowed by 
> the proposal. *

Again, in the grammar.  The "local::" is an alternative to the
scope prefix "::" in the grammar and having both is not derivable.


>    5) "local::" needs to be permitted in front of type names
> 
>  
> 
> *            It is permitted. This is just a repeat of the previous point.*

And again, I'll repeat my point -- the grammar does not allow
this to be derived.

> *BTW, I have never seen the need to refer to a type in a constraint 
> block - perhaps in a cast - but that is atypical.*


"Typical" is not the point -- complete and correct is.


>    6) the proposal is inconsistent in use of the phrases:
>        "the scope containing the randomize method call"
>        and "local scope"
> 
>  
> 
> *            These two phrases are synonymous in the proposal, which is 
> rather explicit, for example:*
> 
>  ...  followed by a search of the local scope - the scope containing the 
> method call.**
> 
> *Where is the inconsistency? I couldn't find it.*


Why use both terms?  Use one.

>    7) should "in-lined constraint" be "inline constraint"?
> 
>  
> 
> *            No. The current LRM uses only in-line (not inline). The 
> proposal uses only in-line consistently.*

Ok.

>    9) The phrase "Within the in-line constraint, the following rules apply:"
>       is still in the current proposal.  The only new rule here is
>       the one regarding "this" that I objected to above.  This
>       phrasing hides the new rule in a collection of otherwise redundant
>       statements.
> 
>  
> 
> *            This point is not particular to the "local::" proposal, but 
> a disagreement on the current semantics of "this" in the context of*
> 
> *            an in-line constraint. I simply restated in the proposal 
> what I believe the rules are now. This disagreement is orthogonal to *
> 
> *local:: and needs to happen if we are to avoid divergence of the 
> existing LRM features.*


You are making explicit an interpretation that I disagree with.  If
you drop that interpretation, fine.  Otherwise my objection stands.


> *            Specifically, you state that "this.x" and "this.y" can 
> cause "this" to bind to two different object in the scope of the same *
> 
> *constraint block, and I find that extremely confusing, error prone, and 
> ultimately fragile.*
> 
>  
> 
>    If my 1858 proposal is accepted, I can likely live with some
> 
>    of the problems (1-5 above) since they can be avoided in the
> 
>    alternate syntax.  If the alternate syntax is not accepted, this
>    proposal needs to be made much more robust about the potential
>    bindings of various forms of names.
> 
>  
> 
> *            Gord, I find this last statement somewhat intellectually 
> dishonest.*



I take extreme issue with this statement and find it personally
insulting.

I'll not retaliate in kind though I am very tempted.



> *Either there are serious problems with the proposal and it should be 
> voted down or it has minor issues that may be addressed by *


Those are not the only options -- your proposal as written
grammatically limits the context of "local::" to "typical"
uses and doesn't allow for things that I care about.  My
proposal doesn't have those deficiencies.

So in *addition* to permitting what I care about, allowing
the limited version that you proposed as well as the general
form I proposed would be more flexible.

If you are prepared to deal with all the deficiencies that I've
identified, then your proposal would regain equivalent
expressability although I will continue to object to your
interpretation of "this." and "super.".


> *friendly amendments, and thus does not merit a negative vote. You have 
> done neither.*


Please see my comments about the grammar above.

Those problems must be addressed and it wasn't at all clear that
your "intent" was that all of that be allowed since you were only
addressing the "typical" uses.


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.