X3J3/96-161 Date: October 25, 1996 To: X3J3 From: David Epstein Subject: Replies to Henry Zongaro comments Below is a copy of the note from Henry (with the comments on N1192) with replies from the Project Editor on lines that follow ##P.E.Reply> The reply of ##P.E.Reply> ##Yes. means that N1192 has changed in attempt to fix the item. David ------------ Replies to note from Henry Zongaro --------------------- In Part 1: - Change "defines a conditional compilation language definition" to "defines a conditional compilation language facility" ##P.E.Reply> ## Yes. In Part 4: - You need to specify the syntactic conventions used, in a manner similar to that used in Section 1.6 of Fortran 95. In particular, define what the meanings of "[]", ". . .", etc. Or at least refer the reader there. ##P.E.Reply> ## Yes. - You need to define the CoCo data types, even if it's just in terms of the Fortran data types. ##P.E.Reply> ## Unclear. ## Why only the data types? Section 2 of Part 1 also has words for Data ## value, Data entity, Data object, Variable, Constant, Expression, ... ## How much of Part 1 Section 2 needs repeating? ## My reply assumes that you where referring to Section 2 of Part 1. - In rule R303, digit-string is undefined. ##P.E.Reply> ## Yes. - In rule R305, rep-char is undefined. ##P.E.Reply> ## Yes. - I believe you need a constraint after R306: "Constraint: must have the PARAMETER attribute." ##P.E.Reply> ## No. ## This is not found in Part1 R307 - In 3.2, in the discussion of coco character context, you need to specify which characters are permitted. You should be able to scavenge from Fortran 95 for this. ##P.E.Reply> ## Unclear. ## Where do you see this in Part 1? Part 1 Section 3.3 does not ## mention anything along those lines. - In 3.2, the 4th paragraph, states that "each source line may contain from 0 to 132 characters". I'm worried about the effect this might have on a processor which is expecting fixed form output from CoCo processing. I haven't thought through the implications yet, but I just wanted to mention that it's worrying me. ##P.E.Reply> ## Noted. ## No worries that I can see as the CoCo directives also follow the ## free source form rules on continuation and other issues. - In 3.2, the 4th paragraph states that "if a line contains any character that is not of default kind". I'm not sure how this can happen - from R305, I assume that there is only one kind of character supported, which would be default. This means that in comment lines, only default kinds of characters would be permitted (3.2, paragraph 3). I assume that outside of a character context, only default kinds of characters are permitted, although this is not stated. All of this together says that only default kind characters are supported. ##P.E.Reply> ## Yes. - In 3.2, the 5th paragraph states that "A sequence of blank characters outside of a coco character context is equivalent to a single blank character." Does this impact the 132 character limit described in paragraph 4? In particular, could I have '??', followed by 130 blanks, followed by "INTEGER :: I" be accepted as a valid directive line? ##P.E.Reply> ## No. ## See Part 1 Section 3.3.1 - In 3.2.3.2, the 1st paragraph states that "An '&' shall be the first nonblank character after the on the next line". This implies to me that you can't have intervening coco comment lines - which is a good thing, but you might want to make it more explicit. ##P.E.Reply> ## No. ## Section 3.2.3.2 is for character context continuation. - In 3.2.3.2, make sure to note that INCLUDE lines are still not permitted to be continued. ##P.E.Reply> ## No. ## Section 3.3 (assumed you did not mean 3.2.3.2) references Part 1 Section ## 3.4 for these words as well as others. ## If you prefer, we can remove the words: ## ## Included source text cannot directly or indirectly include itself. ## ## on the same grounds. Those words are in there to emphasize the ## difference between CoCo and fpp. - In 4, there needs to be some description of what the type declaration statements do. Namely, that they specify the types of the s listed. ##P.E.Reply> ## Yes. You also need to indicate that if PARAMETER appears in the , the s have the PARAMETER attribute. ##P.E.Reply> ## Unclear. ## It would help me if you pointed out where this is mentioned in Part1? - In 4, the constraint after R403, I think this needs to be rephrased as: "Constraint: The type of a shall not be specified more than once." or something along those lines. ##P.E.Reply> ## Unclear. ## How is this better? What about ??INTEGER :: NAME, NAME ## Do the current words truly need more standardese? - In 5.1, the 2nd constraint after R501. The same statement is true of s, and should appear in some constraint as well. ##P.E.Reply> ## Yes. - In 5.2, you need to specify the meanings of the expressions in the same way that Section 7 of Fortran 95 does. ##P.E.Reply> ## Unclear. ## Could you be more specific? Part 1 Section 7 is quite large. - In 5.4, a note after R512 indicates that "Initialization expression is specified in part 1. . . ." You can't rely on that definition of initialization expression, since that specifies what it means for a Fortran expression to be an initialization expression. These are CoCo expressions. ##P.E.Reply> ## Yes. - In 5.4, delete note 5.1 since it doesn't really give the user more information. ##P.E.Reply> ## Yes. - In 6.2.2.1, what does it mean for a line to be a "possible Fortran statement"? I think this needs to be reworded. ##P.E.Reply> ## Yes. - In 6.2.2.2, define "noncoco processing" - or reword the sentence. ##P.E.Reply> ## Yes. - In 6.2.2.2, Note 6.3 doesn't describe the handling of lines in a TRUE block or outside of an IF block. ##P.E.Reply> ## Yes. - In 7, why not use something like "MESSAGE" or "PRINT" rather than "ERROR", since the purpose of these things is not necessarily for error situations. ##P.E.Reply> ## No. ## The purpose is indeed for error situations only. - In 7, the last sentence Change "STOP specifies that the programmer desires to stop processing." to "STOP halts coco processing." Otherwise, it sounds as if the coco processor could ignore the desire. ##P.E.Reply> ## Yes. - In 9.1, it's specified that "A processor shall accept coco programs. . . ." Is a processor permitted to place limitations on the coco program, in the same way a Fortran processor might place limitations on a Fortran program? ##P.E.Reply> ## Yes. - In 9.2, a coco program might be nonconforming in other ways. For example, it might have an integer overflow or a division by zero, neither of which violates syntax or constraints. ##P.E.Reply> ## Yes. - In 10, the 1st paragraph, move the 3rd sentence, which begins, "For example," into Note 10.1. ##P.E.Reply> ## Yes. - In 10, the list after Note 10.1 Delete "either". Change "PARAMETER or" to "PARAMETER;". Change "(R501) or" to "(R501); or". ##P.E.Reply> ## Yes. - In 10, delete Note 10.2 since it doesn't add clarify anything that shouldn't have been clear already. ##P.E.Reply> ## No. ## Some notes are needed and this one is helpful to some readers. - In 10, R1001 to R1003. I'm not convinced that the option syntax should be described. You've given suggestions as to how the values could be communicated to the processor - I think anything more is beyond the scope of the standard. For instance, the Fortran standard doesn't specify how the processor is to be told whether a file is in fixed or free source form, just that there needs to be some way. ##P.E.Reply> ## Unclear. ## Without R1001 to R1003 there cannot be constraints and those constraints ## are needed. - In Annex A, the output of Example 1, I believe all of the output lines should begin with "!??" or "!?>" instead. Otherwise, they won't be treated as comments by a subsequent Fortran processor. ##P.E.Reply> ## Yes.