Hi Neil, Mehdi, and all, I've uploaded a new version of 1447, which is a thorough scrub - almost everything has been updated. Mehdi, please add this to the email vote. Neil, I've attached a file with answers to your detailed comments. I do not believe I am adding or changing any behavior that was not already the intent of the committee. --Mike Neil Korpusik wrote: > Hi Mike, > > Attached is my feedback on the proposal for 1447. > > I hope that others start reviewing this writeup since it takes > a fair amount of time to work through all of it. There is no way > that we will be able to go through it in a conference call, it would > take way too much time for that. > > Neil > > > > Michael Burns wrote On 11/28/07 05:49 PM,: > >> Hi folks, >> >> I've uploaded the latest revision of the proposal for 1447: >> >> http://www.eda-stds.org/mantis/file_download.php?file_id=2866&type=bug >> >> In addition to Shalom's issues, it also contains updates about queues >> related to 1702. Hopefully the two are now de-entangled. >> >> --Mike >> >> >> > > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. > 1. Page 1, 7.4 > > There is a problem with the wording in the following sentence. The issue is > that an array has to have at least one dimension. I think that most people > will understand what you currently have here, but we may want to re-word it > to be more precise. > > From: "An array may have any number of unpacked dimensions." > To: An array may have one or more unpacked dimensions. [MB] The intention here is to refer to arrays in general, not just unpacked arrays. General arrays do not need to have any unpacked dimensions; they can all be packed. I could envision doing more work on 7.4 to clarify terminololgy - specifically, that an array must have at least one dimension (packed or unpacked), an array with all packed dimensions is a packed array, and an array with at least one unpacked dimension is an unpacked array (correct?). However, I'd rather minimize the number of changes for reviewers to absorb. If people think it's necessary, I'll be happy to add it. > > 2. Page 2, example at the top of the page > > The following line seems to have a typo in it. > Shouldn't the first ";" be a ","? > > From: int A[2][3][4], B[2][3][4]; C[5][4]; > To: int A[2][3][4], B[2][3][4], C[5][4]; [MB] Yup; fixed. > > 3. Page 2, 7.5 > > Typo: There is an extra period after [] in the next to last sentence. [MB] Fixed. > > 4. Page 2, 7.5 > > The new text has the following: > > "The syntax to declare a dynamic array is as follows: > > data_type array_name index_list; > > where data_type is the data type of the array elements and index_list > contains one or more dynamic dimensions, each indicated by []." > > Unfortunately this is now a bit inconsistent with the previous paragraph > which defines a dynamic array as the following. We only have a dynamic > array if the slowest varying dimension is dynamic. > > "If a dynamic dimension is the most slowly varying dimension, the > entire array is a dynamic array. A dynamic dimension in any other > position defines a dynamic subarray" > > One possible way to correct this would be to use the following: > > "The syntax to declare a dynamic array is as follows: > > data_type array_name [] [index_list]; > > where data_type is the data type of the array elements and index_list > contains one or more additional dimensions. A dynamic dimension is > specified using []." [MB] Yes, that would be correct; however, I'm thinking that I don't like that little bit of syntax at all. It isn't a real grammar box. The only significant information I can see being conveyed here is that dynamic dimensions are denoted using []. "Dynamic array" is already defined in the text; I don't think it needs its own special syntax description. I've removed the pseudo-syntax and done some rewording around it. The examples below this part give a clear enough idea of what a dynamic array looks like. > > 5. Dynamic dimension versus dynamic array dimension > > The proposal uses both of the following terms in many places. > dynamic dimension > dynamic array dimension > > Shouldn't one term be used consistently throughout? [MB] I think so. I choose "dynamic array dimension", so that dynamic array dimensions, associative array dimensions, and queue dimensions are the kinds of dimensions found in dynamic arrays, associative arrays, and queues; this sounds nice to me, even though it's a little longer. I've made the change, plus a little rewording to avoid things like "the array's dynamic array dimension". There is a major change I am making related to this. The proposal as I inherited it extensively uses the concept of sizing or initializing a dynamic array dimension. This concept is nonsense. Dynamic arrays are sized, not dynamic array dimensions. A dynamic array dimension can represent many dynamic arrays, each of which requires explicit initialization and can have a different size: int foo [0:1][]; ... foo[0] = new[4]; foo[1] = new[37]; // same dimension, different sizes. > > 6. Page 4, Syntax 5-1 > > I assume that you intend to retain the "box" showing the grammar productions. > There should be at least a one-liner shown here, so that the Editor will > know where to place it with respect to the new text. [MB] Yes - fixed. > > 7. Page 4, redundant sentence can be removed, see Mantis 2176 > > The Champions flagged an issue with the text in the next to the last > paragraph. See mantis 2176. The first sentence of this paragraph can > be removed. [MB] Fixed and noted. I am of the opinion that the entire rest of the paragraph should also be removed since it doesn't describe what is intended very well. I'm pretty sure the intention is to say that the size in the square brackets "wins" over the size of the array in the initialization expression. This is a semantic issue, whereas operator precedence is generally a syntactic property. There is never any ambiguity in parsing a dynamic array _new_. Besides, this behavior is more approrpiately described in text lower down after the semantics of size and initialization expression are described. However, I'm doing tons of edits here; I'll leave this as-is unless folks ask me to change it. > 8. Question > > Can part of a multidimensional array be assigned to before all dimensions > have been constructed? The example in the middle of page 5 shows this. [MB] From a user and LRM perspective, I see no semantic problems with doing this. Implementors will have to speak up if it would present implementation problems. Of course, the part being assigned to must have been constructed already. > > 9. Page 5, initialization expressions that contain dynamic dimensions > > "When an initialization expression contains dynamic dimensions that vary > more rapidly than the dimension the new constructor is sizing, the > corresponding dimensions in the left-hand side array or subarray adopt > those sizes." > > This appears to be an enhancement. As written, this behavior is > underspecified. The most obvious problem case occurs when the array on > the LHS has dynamic dimensions in different places than those which > occur in the expression on the RHS. It was my understanding that this > initialization process was only meant to occur on the most rapidly varying > dimension. I suspect that this new enhancement will be more of a problem > than a help at this point. [MB] This sentence is gone in the new version. Any subarray initialization behavior will be inductively defined. I don't intend to introduce any enhancements here. > 10. Resizing dynamic dimensions - page 5, paragraph below the first example > > "Resizing a dimension is destructive, so no data from a dimension's > previous sizing operations is saved for user access." > > As I understand it, the data is lost for the resized dimension and any > corresponding more rapidly varying dimensions. For multidimensional arrays > it is possible to resize portions of the array while retaining the > current data for other portions. I'm not sure that this is clear in > the proposal. More examples might help in this regard. [MB] I am attempting, in my new edits, to make clear that dimensions are not sized, resized, or initialized - dynamic arrays have size, not dynamic dimensions. For arrays-of-arrays, the "inner" arrays are data - they are not preserved when the outer array is resized. > 11. Page 5, paragraph below the 2nd set of examples > > "Dynamic array element values are set when a legal initialization > expression contains them or when they receive default values." > > This sentence isn't too clear about the non-default case. The portion that > is unclear is "when a legal initialization expression contains them". [MB] Agreed - this is no good. I am reworking this section. > > 12. 7.5.2 Size() > > There isn't anything in the proposal about 7.5.2 but now that I read > through the proposal it makes we wonder about the built-in methods for > arrays that have dynamic dimensions but have a fixed sized slowest > varying dimension. The proposal refers to these as dynamic sub-arrays. > This creates the need for some changes to the descriptions of the > built-in methods. > > From: "The size() method returns the current size of a dynamic array or > returns zero if the array has not been created." > To: "The size() method returns the current size of a dynamic dimension or > returns zero if the dynamic dimension has not been created." [MB] Again, I shall clarify that size() is called on dynamic arrays, not dimensions. If I do a good job elsewhere, it will not need to be said that it doesn't matter how the reference to the array is specified. > > 13. 7.5.3 Delete() > > From: "The delete() method empties the array, resulting in a zero-sized > array." > To: "The delete() method empties the dynamic dimension, resulting in a > zero-sized dynamic subarray." [MB] See size() above. > > 14. Page 6, last paragraph, 2nd bullet > > From: "If a fixed dimension in the source array..." > To: "If a fixed-size dimension in the source array..." [MB] This sentence no longer exists in the reworked version. > > 15. Page 7, examples > > int D [3][][]; // multiple dynamic dimensions > D[3] = new [2]; // initialize slowest varying dynamic dimension (see 7.5.1); > D[3][0] = new [100]; > A = D[3]; // A[0:1][100:1] and subarray D[3][0:1][0:99] both ... > > 1) Array D ranges from 0:2, "D[3] = " is not valid. > 2) "D[3][0] =" is not valid. > 3) "A = D[3];" is not valid. [MB] Yes; fixed. > > 16. Page 7, range specification for dynamic dimension sized by new() > > It appears that the only place where the range specification created by > new() is described is within the examples on page 7. There should be a > description of this in 7.5.1 [MB] I'm not sure what you mean; dynamic arrays do not have a range like fixed-size arrays; they just have a size. Elements are indexed in the same way for all dynamic arrays. > 17. Page 9, A.10, item 40. > > The example in the middle of page 5 violates the restriction of this > footnote. > > int isrc[][][], idest[][][]; > isrc = new [2]; > isrc[0] = new [3]; > isrc[1] = new [5]; > idest = new [2] (isrc); // set size for idest[0] = 3 and for idest[1] = 5 [MB] Footnote removed. > 18. Page 9, A.10, item 41. > > I have no idea what this is trying to say. [MB] The BNF has been reworked as well; there are no longer any proposed new footnotes.Received on Tue Dec 11 01:29:38 2007
This archive was generated by hypermail 2.1.8 : Tue Dec 11 2007 - 01:30:22 PST