Gord, I don't know how you reached such conclusions. I don't believe your deductions are supported by the text of the proposal. More details below. Arturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Friday, December 14, 2007 7:20 AM To: Mehdi Mohtashemi Cc: Arturo Salz; 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 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). 2) The change does not permit "local::this.x" This is untrue. Where is this disallowed? 3) "super" and "this" are not symmetric in the proposal This is untrue. Where does the proposal treat super and this asymmetrically. 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. 5) "local::" needs to be permitted in front of type names It is permitted. This is just a repeat of the previous point. BTW, I have never seen the need to refer to a type in a constraint block - perhaps in a cast - but that is atypical. 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. 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. Event then, this is no reason to reject the proposal, it is an orthogonal issue to replace "in-line" by "inline" everywhere. 8) the new proposal still talks about "The scope...from inner to outer...". The list of scopes there is incomplete and incorrect. This should be rewritten to avoid listing the scopes. As I wrote earlier. That language is existing verbiage in the LRM, and not a part of the proposal. We can certainly change that language, but that is not even the issue of this Mantis. 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. 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. Either there are serious problems with the proposal and it should be voted down or it has minor issues that may be addressed by friendly amendments, and thus does not merit a negative vote. You have done neither. No on 2055 - same reasons as others. Yes on the remainder. Gord. Mehdi Mohtashemi wrote: > [Modification to the email ballot: > Removed: (mistakenly placed in the email ballot) > a) 1809: mistakenly placed, sv-bc issue > b) original proposal file name for 1858 > 1858-randomize-constraint-resolution.htm > > Added: replaced 1809 with mantis 974 (CLOSE) > > Please use the following list to cast your vote by > midnight Friday December 14 2007. > It would be great to have voting done by that day, > so that given an extension from p1800 working group > we can resolve other issues on Monday December 17th > meeting. > - Mehdi > > -------------------------------------------------- > > We are conducting an email vote based on December 10 2007 sv-ec meeting. > The time period for this ballot is 3 days, the voting closes on December > 15 2007, 12 am. Please send your vote no later than Friday December 14 > 2007 11:59pm PST] Please read guidelines and instructions for each > mantis item listed since there may vary depending on the mantis item. A > few mantis items may have multiple proposals, you should vote for each > proposal with YES/NO vote. > > Individual eligible members' email is used in TO list since there maybe > a delay with sv-ec email reflector. Other regular attendees as well as > sv-ec alias are listed in the CC part. At the moment the reflector site > does not come up. > > The following mantis items are listed for voting: > section a) Mantis set related to queue manipulation, covered by 1702 > (Note 1702 was approved on December 10 2007) to be closed. > 412, 516, 517, 518, 519, 520, 521, 522, 801, 974 > > section b) > 958, 1447, > 1858 [contains two proposals] > 2055, 2137, 2181 2227 > > Operating guidelines for sv-ec email vote: > - Only 3 days to respond (Midnight Friday December 14th 2007) > - An issue and its proposal passes if there are zero ** NO ** votes > and at least half of the eligible voters respond with a YES vote. > - Any NO vote must be accompanied by a reason. > This issue will then be up for discussion at the next conference > call. > - If there are more than one proposal indicated per mantis > item, please cast your vote for each and every proposal. > - Please indicate any friendly amendment that you think will change > your vote to a YES, this will help with completing our task. > > As of the December 10 2007 meeting, the eligible voters are (total 15): > > Arturo Salz, > Cliff Cummings > Dave Rich > Francoise Martinolle > Neil Korpusik > Ray Ryan > Gordon Vreugdenhil > Steven Sharp > Stu Sutherland > Heath Chambers > Don Mills > Mark Hartoog > Mike Mintz > David Scott > Mike Burns > > > Please mark your vote below by an x. If No, then specify a reason. > Send it to the reflector. > 412, 516, 517, 518, 519, 520, 521, 522, 801, 1809 > > Section a) > CLOSE following mantis items, covered by 1702 > 412 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000412 > > 516 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000516 > > 517 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000517 > > 518 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000518 > > 518 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000519 > > 520 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000520 > > 521 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000521 > > 522 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000522 > > 801 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000801 > > 974 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000974 > > > Section b) > 958, 1447, > 1858 [contains two proposals: > 1858-randomize_with_syntax.htm] > 1858_local.pdf > 2055, 2137, 2181 2227 > > > 958 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=000958 > > 1447 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0001447 > > 1858 [Multiple proposal files] > 1858-randomize_with_syntax.htm ___ Yes ___ No > 1858_local.pdf ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0001858 > > 2055 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0002055 > > 2137 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0002137 > > 2181 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0002181 > > 2227 ___ Yes ___ No > http://www.eda.org/svdb/bug_view_page.php?bug_id=0002227 > > > > section a) > 412 5.14.1 Queue operator examples use aggregate constructors > incorrectly > 522 use of concatenation in 5.14.2 (Francoise) > 521 pattern assignment for queues (Francoise) > 520 example of queues assignment (Francoise) > 519 section 5.14,empty array literal syntax (Francoise) > 518 queues and arrays (Francoise) > 517 concatenation syntax usage section 5.14 (Francoise) > 516 5.7 and 5.8 description of type compatible arrays > 801 Errors in assignment pattern in 5.4 example > 974 comparison of dynamic arrays/queues to 1-dimensional fixed > arrays > > section b) > 1858 Name binding in inline constraints > two separate proposals > 1447 Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 > and 5.8) > 958 dynamic array size method unclear when empty > 2055 coverage bin distribution is not even > 2137 Some assertion contexts should be procedural > 2181 Ambiguity implicit declaration of production variables in > randsequence > -- -------------------------------------------------------------------- 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 Sat Dec 15 03:16:56 2007
This archive was generated by hypermail 2.1.8 : Sat Dec 15 2007 - 03:17:27 PST