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

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Fri Dec 14 2007 - 10:01:51 PST
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