[sv-ec] email vote closed December 15 2007 results

From: Mehdi Mohtashemi <Mehdi.Mohtashemi_at_.....>
Date: Sat Dec 15 2007 - 23:58:49 PST
The email ballot closed on December 15 2007, here is the result.

 The summary results: 8 items passed, 9 did not pass.
   Passed:  
          section a)  CLOSE   412, 517, 518, 519, 521, 801
          section b)  958, 2227

   Did not pass:
          section a)    516,  520, 522, 974
          section b)   1447, 1858 [both proposals], 2055, 2137, 2181

15 members were eligible to vote.
10 voted, 5 did not cast vote.
  Voted: 10
   David Scott, Mike Burns, Mark Hartoog,  Francoise Martinolle, Gordon
Vreugdenhil
   Don Mills, Ray Ryan, Steven Sharp, Neil Korpusik, Arturo Salz,

  Did not cast vote: 5
   Cliff Cummings, Dave Rich, Stu Sutherland, Heath Chambers, Mike Mintz

Here is the full vote result, comments are included.
-------------------------------------------------------
 Section a)
CLOSE following mantis items, covered by 1702
 412  ___ Yes   ___ No  
     Yes  111111111            No   ---------


 516  ___ Yes   ___ No     
     Yes  1-1*1-11-            No   -1-*-1--1

   No votes:
    Mike B.: 516 should really be related to 1447; 1702 doesn't really
apply.
    Don Mills: 
      First line of description in 1702:   "This issue comes to group 
      together the queue syntax issues 412, 517-521, 801:"
      516 is on arrays and is not directly related to queues as
discussed in 1702.

    Neil:
         Now covered by 1447.
       If 1447 passes I will agree to closing 516 as being covered by
1447.
    Francoise marked x but no reason was given. 

 517  ___ Yes   ___ No     
     Yes  111111111            No   ---------


 518  ___ Yes   ___ No     
     Yes  111*11111            No   ---*-----
     *  Francoise: nothing was recorded



 519  ___ Yes   ___ No     
     Yes  111111111            No   ---------



 520  ___ Yes   ___ No     
     Yes  1-1111111            No   -1-------

    No vote:
   Mike B.:
      The comments in the example code of 7.11.1 "Queue operators" 
      should be changed to not explain the operations in terms of 
      append, prepend, insert and delete since these operations have 
      different semantics w.r.t. outdating of references.



 521  ___ Yes   ___ No     
     Yes  111111111            No   ---------

 522  ___ Yes   ___ No     
     Yes  11111-111            No   -----1---
   No votes: 
   Don Mills:
      Jonathan - is 522 also covered in 1702?  It is not listed as 
      one of the items in the description.  It is possible that it is 
      indirectly covered by all the other items listed, but I just 
      want to check with you first.  If it is, I will change my vote to
yes.




 801  ___ Yes   ___ No     
     Yes  11111111            No   --------

 974  ___ Yes   ___ No  
     Yes  1-1-1-11-            No   -1-1-1--1
 
    No Votes:
    Mike B.:
     974 is addressed by 1447, not 1702.
    Francoise: same as above.
    Don:   First line of description in 1702:   "This issue comes to
group 
           together the queue syntax issues 412, 517-521, 801:"
           974 is on arrays and is not directly related to queues as
discussed in 
           1702.
     Neil:
        I believe that this is actually covered by 1447 and not 1702.

 


  Section b)
      958, 1447,
     1858 [contains two proposals:
              1858-randomize_with_syntax.htm]
	        1858_local.pdf
     2055, 2137, 2181 2227 


 958  ___ Yes   ___ No  
     Yes  111111111            No   ---------

   Notes;
   Mike B.: 
     I think a related errata should be filed, in that an 
     array_dimension_function cannot in general return a meaningful 
     result for a dynamically sized dimension whose dimension expression
is not 1.

  Neil:
        I reviewed the 958-2.pdf of Dec 14th
        Note that on page 2 of the proposal there is the following
sentence
        fragment shown in black text, which is not part of the current
LRM. I
        would like to see this removed from the proposal.
           "If any of these functions is called with arguments (v, n)
where v
            denotes some array variable and n is a dimension number
greater
            than 1,"
  

 1447  ___ Yes   ___ No  
     Yes  1111111-*            No   -------1*
 
     No Vote:
   Steven:
     I have a problem with the text for 7.4 that says
     "Unpacked arrays are formed from any variable data type, 
     including other packed or unpacked arrays (see 7.4.5).  
     Unpacked fixed-size arrays may also be formed from net data types."

     This text suggests an incorrect conceptual model for variables 
     and nets. It suggests that a variable of array type has an element 
     type (i.e. a "variable data type") that is somehow different 
     from the element type of a net of array type (i.e. a "net data
type").  
     It suggests that a net is somehow a data type, and a net array 
     is an array of those.  This is incorrect.  A variable and a net 
     can be declared with the exact same array data type.  Nets are 
     restricted to a subset of the types allowed for variables, but 
     then has the same data type as a variable of that type.

     I am not sure how this text should be fixed, since I am not 
     sure why it was included.  One possible solution would be to 
     drop the word "variable" from the first sentence, and then drop 
     the second sentence about nets entirely.

     Depending on the purpose of those sentences, it might make sense 
     to add new sentences.  Perhaps something like: "Any type of array 
     is allowed as the data type of a variable.  Only fixed-size arrays 
     are allowed as the data type of a net."

     The wording is a little difficult, since we don't want to say 
     that a net must be a fixed-size array.  We want to say that if 
     it is an array, it must be a fixed-size one.  Alternately, we could

     say that a net shall not be a dynamic array, associative array, 
     or queue.  But shouldn't this really be stated in 6.6?  That
section 
     says that a net can be an unpacked array, but should really 
     say a fixed-size unpacked array.

    abstain (did not cast vote)
    Neil:
        I didn't have time to review this update in detail.


 1858  [Multiple proposal files]
  1858-randomize_with_syntax.htm       
     Yes  11--1-*---            No   --111-*-11   abstain -----1*1--
   No votes:
   Mark H.:    I think this syntax is confusing and is not needed.
   Francoise:   No need for 2 different ways to do the same thing.
   Neil:  I find this syntax to be somewhat obscure. I prefer the
local:: syntax.
   Arturo:
    The argument passing syntax for specifying binding is problematic. 
    No other construct uses this name binding feature. Do the names need

    to exist in the class scope or is it an error to provide an un-used 
    name? What about expressions such as "super.x" ?
    I will change my vote to "yes" if the proposal is limited to
providing 
    the alternative search semantics that bypasses the target 
    object and starts the search in the local scope.

   Note, Ray did not cast a vote, mentions preferances.
   

  1858_local.pdf  
     Yes  1111--*-11            No   ----1-*---    abstain -----1*1--
    No Votes:
   Gord:
   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.
   2) The change does not permit "local::this.x"
   3) "super" and "this" are not symmetric in the proposal
   4) "local::" needs to be permitted in front of a class scope
      identifier
   5) "local::" needs to be permitted in front of type names
   6) the proposal is inconsistent in use of the phrases:
       "the scope containing the randomize method call"
       and "local scope"
   7) should "in-lined constraint" be "inline constraint"?
   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.
   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.

   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.

  Ray:
      1) I also feel the interpretation of "this" is changed, 
      but following slightly different interpretation. The current 
      LRM states that the lookup starts in the randomize class OBJECT, 
      (not the in context of the randomize method). The name "this" is 
      valid in the context of a non-static method (like a hidden 
      parameter), it is not a property of the class object. So 
      "this" would not be found in the scope of the class object - 
      thus it should be resolved in the scope in which the randomize 
     call occurred.
      2) I'd also expect to be able to apply the local:: prefix to 
      a hierarchical name. For example, "local::x.a" - where 'x' 
      is a local struct containing a member 'a'. The current 
      text seems to only allow "local::" as a prefix for an "identfier".

      Otherwise I agree with the intent of both proposals. I prefer 
      Gord's text for specifying the default name resolution 
      (in the absense of the identifier list).

  
 2055  ___ Yes   ___ No  
     Yes  -----1-1-          No  11111-1-1

   No vote:
   David Scott: No on 2055 (repeating my vote against the same proposal
on October 26) 
      NOTE: 2055 IS A REDUNDANT VOTE. THE PROPOSAL FROM OCTOBER 20 HAS 
      NOT BEEN MODIFIED SINCE THE LAST VOTE ON OCTOBER 26. My objections
previously were:

      There was nothing unclear in the previous description; this is an 
      arbitrary change and introduces incompatibility with 1800-2005. I 
      think we need to debate how compelling is this change for typical
users 
      and weigh that carefully against the incompatibility.

   Mike B.: same reason as others - no new proposal since last vote.
   Mark H.:    An enhancement that is not backwards compatible.       
   Francoise: Same reason as others - no new proposal since last vote.
   Gord: same reason as others.
   Ray: same objection as others.
   Neil: Same reasons as others have already stated.
          Although I would like to clarify that I don't believe it was
ever
          voted on in the past.  The minutes show that we tabled it
without
          voting.
   Arturo:
       Not backwards compatible.
       I will change my vote to "yes" if this behavior is triggered by 
       a different syntax.


 2137  ___ Yes   ___ No  
     Yes  11-111111-            No   --1------1
 
   No Votes:
    Mark H.: 
      Why are only sequence match subroutine calls being added
      as procedural context? What about sequent match assignment 
      and increment?         

   Mike B:
      Good point, which I believe you made before and I 
      failed to capture. I don't think it matters for increment, 
      but assignment can do things like refer to an object data 
      field or function method, which must be in a procedural context to
be legal.

      It would be straightforward to change this to say that 
      sequence_match_item (which includes assignments, increment, and
      subroutine_call) is a procedural context. If there are no
objections, 
      I can do this tomorrow. Would that change your vote to a yes?

   Arturo:
      This is not needed - not in this section, which describes 
      structured procedures, not function activation. It adds more
confusion.

      Assertions already stipulate that functions and methods may be
called 
      at the end of a sequence match. Assertions also support procedural

      operations such as assignment and increment.
      Action blocks *are* procedural - that should be stated in section
16.14.


 2181  ___ Yes   ___ No  
     Yes  --11111--1            No   1-------1-             abstain:
-1------1--

  No vote: 
  David Scott: No on 2181 just owing to confusion.
       I apologize if I wasn't paying attention sometime and am 
       arguing from ignorance, but I am confused between "rules" and 
       "productions". The text of 17.17 defines what is a "production" 
       but not what is a "rule". The BNF in Syntax 17-2 seems to show 
       productions containing rules which in turn contain productions, 
       so that doesn't help me.

       Consequently, I can't tell if there are red strike-throughs 
       missing in this proposal. Is the new third paragraph supplemental

       to the first or supposed to replace it? What led me to think that

       red strike-throughs are missing is that "For example:" in the 
       second paragraph is followed by another paragraph, not an
example. 
       The second paragraph seems to me surely to be intended as deleted

       (requiring red strike-throughs) -- but I can't tell about the 
       first paragraph owing to my own confusion between "rules" and
"productions".
  
   Neil:
   I will change my vote to Yes, if the following changes are made.
      1)  I don't see any text in red, struck-out.
          I assume that you were planning to strike out the following
sentence.
             "If the same production appears multiple times, then a
              one-dimensional array that starts at 1 is implicitly
declared.
              For example:"
      2) It appears that there is additional text in the current LRM
that
         refers to the existing example.  See page 421, "When executed,
the
         example above displays a..." Adding in the second example where
it is
         currently shown, causes a problem here.

  Abstain: 
  Mike B.:  Lack of time and interest for randsequence.
  Steven: 
   Abstaining, since I haven't thought enough about it.  
   I am not happy with the inability to return multiple values for
repeated 
   productions.  At the same time, it seems that something needs to be
defined.


 2227  ___ Yes   ___ No  
     Yes  1111111111            No   ----------
 
====================================================================


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Dec 16 00:42:17 2007

This archive was generated by hypermail 2.1.8 : Sun Dec 16 2007 - 00:42:57 PST