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