I'm not eligible for this vote, but I have reviewed these proposals and my comments are below. I have not attempted to correlate them with comments from others, so there will probably be some duplication - apologies if so. I can't attend this Monday's call, so you can ignore all this with impunity! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1777 ~~~~ Red has been used for added text, blue for strikeout. Should it be the other way around? One closing ] has been accidentally changed to ) in this excerpt (it was correct in the original LRM text): bins b2 = ( 2 [-> 3:5] ); // 3 to 5 nonconsecutive 2's bins b3 = ( 3 [-> 3:5) ); // 3 to 5 nonconsecutive 3's Friendly amendment: close to the end of the proposal, the long example string 1 2 3 2 3 2 3 2 3 2 3 1 5 5 5 5 5 5 would be much easier to read if it had index numbers associated with it - perhaps like this: 1st sample | 5th 10th 15th | | | | 1 2 3 2 3 2 3 2 3 2 3 1 5 5 5 5 5 5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1371 ~~~~ Clause 16 is now clause 23 in the merged LRM. Presumably the proposal should say which version it's modifying. The first paragraph of the proposal (changes to 16.2/23.2) could perhaps be re-worded to make it clear that a simulation may stop earlier than this if some other code calls $finish. Using the phrase "the simulation shall terminate" seems to exclude that obvious possibility. I find this sentence very hard to understand: Calling $exit from a thread originating in an initial block of a program shall execute a disable fork from within as well as end all initial blocks in that program block. Could I suggest the addition of two commas, and a slight rewording? Calling $exit from a thread originating in an initial block of a program shall execute a disable fork from within, and shall then end, each initial block in that program block. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1384 ~~~~ Clause 4.16 is now clause 6.22.3. Cross-references 7.10 and 7.17 are now 8.10 and 8.17. Clause 8.17 is now 11.8. The following sentence doesn't seem to me to convey what I understand the intent to be: It shall be illegal to stream a class handle with local or protected members except when streaming the current instance this. That sounds as though class-type members of "this" that contain local data can indeed be streamed if you're currently trying to stream "this". It might be preferable to say It shall be illegal to stream a class handle with local or protected members if those members would not otherwise be accessible at the point of use of the streaming operator. That allows me to stream "this" when it is a derived-class object whose base class has protected members, but not if the base class has local members. It also prevents me from streaming "this" if one or more of its members of class type has any local or protected data. I suspect that's closer to the intent? I'm afraid I completely fail to understand the sentence Reconstruction does not modify any internal properties in the target class object. First off, we don't have a very good definition of "reconstruction" at that point in the text ("reconstructed" is used in the previous sentence, but in a fairly casual way). Secondly, the process of "reconstruction" (= unpacking into an object, I presume) most certainly does modify that object's internal properties. I assume the idea is that unpacking never changes the value of any class handle. Would that description be OK? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1707 ~~~~ Trying to describe the behaviour of bitstreaming rigorously iS a reliable way to make my head explode. I would prefer to see a description that used bitstream casting to get to a queue of bits, followed by an algorithm copying the queue of bits into a second queue of bits with appropriate re-ordering, and finally another bitstream cast to get that second queue of bits into the target. However, I agree the new wording is an improvement. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1680 ~~~~ OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1427 ~~~~ I agree with Doug that the original wording is preferable, as it licenses tools to throw an error if the user supplies a negative signed expression. If you want to be specific about the type, you could say that the operand is of type longint but that it shall be illegal for it to have a negative value. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1723 ~~~~ OK. Perhaps we could deprecate the num() method? That would help to explain why there are two identical methods with different names! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1736 ~~~~ OK. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Apr 22 17:37:28 2007
This archive was generated by hypermail 2.1.8 : Sun Apr 22 2007 - 17:38:07 PDT