From maine@altair.dfrc.nasa.gov Wed Jan 10 23:32:04 1996 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id XAA04124 for ; Wed, 10 Jan 1996 23:32:00 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA05551; Wed, 10 Jan 1996 14:25:30 +0800 Date: Wed, 10 Jan 1996 14:25:30 +0800 Message-Id: <9601102225.AA05551@altair.dfrc.nasa.gov> From: Richard Maine To: SC22WG5@dkuug.dk Cc: maine@altair.dfrc.nasa.gov In-Reply-To: <199601051219.NAA05953@dkuug.dk> ("Erik W. Kruyt (+31 71 5276804)"@dkuug.dk) Subject: Re: (SC22WG5.989) X3J3/95-007R2, nesting of scoping and edits content-length: 0 I have the following comments on Erik Kruyt's edit suggestions. > I suggest to change the second occurrence of "statements" in line 3 > of page 14 and "statements" in the title of table 2.2 to "statements > or groups of statements" and replace "Statement Function" in the > first column of table 2.2 by "Statement Function Statement" Although it is certainly true that all of the things mentioned aren't statements, I don't like the term "groups of statements". It is too vague and isn't ever defined in any specific sense. This doesn't really seem like an improvement. I agree that changing "Statement function" to "Statement function statement" is a pretty easy fix to one part of the problem. I'll add this to my proposed fix list (but note that only the first letter of the phrase is capitalized, not each word). > 3. Page 194, lines 24-26 of X3J3/95-007R2 states that an external > subprogram definition specifies an implicit interface for the > procedures defined in that subprogram. However, the interface is > explicit for a recursive subroutine or a recursive function with a > separate result name within the external subprogram (page 193 lines > 1-2)! So the wording on page 194 has to be changed. Agree that this is at least confusing. I don't have good substitute wording handy and I'm not confident that I would come up with wording that doesn't cause problems elsewhere, so I plan to do nothing here unless I get more specific direction and agreement. > Add the entry "construct" to the index with sub-entries: case, do, > executable, forall, if, where. There were several other good suggestions in the public review to add index items. It would take a lot more time than I have available to do all the work of adding them, particularly those without more specifics than this (i.e. detailing exactly what references should go with each index entry). > Make note 3.8 analogous to note 3.9: "In fixed source form, an > exclamation point (!) or semicolon (;) in character position 6 > indicates a continuation of the preceding noncomment line unless it > appears within commentary indicated by a "C" or "*" in character > position 1 or by another "!" in character positions 1-5." I agree that there are some problems here. I'd propose a slightly different fix. Note 3.8 is actually incorrect without the additional qualifications, so this should at least get fixed. When 3.8 is fixed, it will say almost the same thing as 3.9. Furthermore, note 3.9 has only tenuous connection with the section it is in. I'd propose merging the two notes as follows. Use most of the text from 3.9, except begin with: An "!" or ";" in character position 6... Put the resulting single note where note 3.8 currently is. I'll add this to my proposed fix list. > - Page 34, Note 4.9. > Change the header to make it comparably to that of note 4.5: > "Examples of unsigned and signed real literal constants are:" I'd make the opposite change - delete "unsigned and" from note 4.5. We don't actually have anything called an "unsigned integer literal constant" defined in the bnf, which could make this potentially confusing as it is. However these are all valid signed literal constants as defined in the bnf. > - Page 35, Note 4.10. > Change the header to make it comparably to note 4.5: > "Examples of unsigned and signed complex literal constants are:" > Add an example of a signed complex literal constant: > "-(0.45E-4, -1.0)" No such term as a "signed complex literal constant" is defined. This example is not a literal constant at all (although it is a constant expression). > Change the last example to have an example with a named constant kind: > "(4.0_4, 3.6E_QUAD) > where QUAD is a scalar integer named constant." This obscures the example of the real and complex parts having different kind numbers (since QUAD could concievably equal 4). That seems an especially pertinent example of an issue relevant only to complex, so I'd object to changing it. I'd have no real objection to adding an example with a named constant kind, though I don't see that it is particularly needed, since the real examples do show this. > The page frame of some chapters of the printed document (A4) appear > to be adjusted lower on the page than others; they have 2 cm more > white on top and 2 cm less on the bottom. I wonder what could have > caused this. Is it the conversion to A4 or does it show op in the US > letter format too? I haven't noticed anything like this, but I could have just missed it. Do you have any specific page numbers to cite? There are a lot of pages in the document and it would be easy enough to miss one or two cases of something like that. One possibility does occur to me - this kind of phenomenon can be caused by physical printer feed problems having nothing to do with the data. Is it repeatable? That is if you print out the same section twice does the problem occur on the same pages? If not, I'd suspect the printer. If it is repeatable, specific page numbers will help. -- Richard Maine maine@altair.dfrc.nasa.gov