From J.Reid@letterbox.rl.ac.uk Fri Mar 21 19:56:15 1997 Received: from letterbox.rl.ac.uk (letterbox.rl.ac.uk [130.246.8.100]) by dkuug.dk (8.6.12/8.6.12) with SMTP id TAA21976 for ; Fri, 21 Mar 1997 19:56:12 +0100 Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Fri, 21 Mar 1997 18:56:03 +0000 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA21904; Fri, 21 Mar 97 18:56:01 GMT Date: Fri, 21 Mar 97 18:56:01 GMT From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9703211856.AA21904@jkr.cc.rl.ac.uk> To: sc22wg5@dkuug.dk Subject: Coco ballot I tried without success to find the pre-LV coco ballot comments on Miles' server. Miles told me that making a summary had got pushed aside by more urgent commitments and he sent me the raw ballots, from which I have made a summary. In case, I am not alone in wishing to see them, here is a copy of my summary. Best wishes, John. ```````````````````````````````````````````````````````````````````````````` Informal Ballot on N1243 (Draft Standard for Conditional Compilation in Fortran) Summary: YES NO Rolison Reid Adams Bierman Muxworthy Epstein Sacks Cohen Martin Dedo Totals 3 7 Detailed votes: ---------------------------------------------------------------------------- I believe that the current draft is ready for | YES | NO | submission to SC22 for its first CD ballot |_____|XXXX| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. The model of conditional compilation presented in the subject working paper suffers from not just one, but two fatal flaws: * It does not standardize common practice (the form of conditional compilation generally accomplished through the use of cpp or cpp-like source processors). * It does not contain contain any facilities whatsoever for macro definition and expansion. Paper N1247, the cpp-like source processing working paper, should be substituted for the "Fortran-like" conditional compilation working paper in all further considerations and voting. I consider it unfortunate that this call for informal review did not mention N1247 in any manner. (signed) Lawrence Rolison (date) 21 January 1997 ---------------------------------------------------------------------------- __________ I believe that the current draft is ready for | | NO | submission to SC22 for its first CD ballot |_____|____| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. (signed) John Reid (date) 22/1/97 Reasons: 1. More work is needed on the typesetting (details below). 2. The SET option should not be processor dependent (detailed suggestion below). 3. I also have some minor comments. 1. Typesetting ^^^^^^^^^^^^^^ a. Add headers and footers, including page numbers. b. Use italic font for bnf terms appearing in the main text and the constraints. c. Justify the main text. d. Use bold for title of section CC3.3.3. e. Use a black square for the bnf continuation symbol. f. Indent constraints as in the standard. g. Reduce the leading in the bnf of section CC6.2.1. h. Left-aflign the text that follows the bold kewords "is" and "or" in the bnf. 2. The SET option ^^^^^^^^^^^^^^^^^ I would like to see the SET option standardized as a coco file that precedes the coco program proper. This could be done with no change to the present semantics, but I think it would be much better to have no special rules and interpret the two files as having being concatenated. This does need changes. I suggest 1. Constants be allowed to be redeclared with the same type and same value. 2. Variables be allowed to be redeclared with the same type. Any initialization is ignored if the variable is already defined. This would make a significant simplication of the present proposal as well as aiding portability. 3. Minor comments ^^^^^^^^^^^^^^^^^ a. CC3.2/-3 Delete line: "Adjacent ..." b. CC3.3 Remove all the special rules for INCLUDE and treat it as in the main standard. c. CC7. Reword. The ERROR directive causes a string to be made available. Its likely use is for the coco program detecting something wrong. The STOP directive causes coco execution to stop. Its likely use is for the coco program detecting something that it cannot handle. ---------------------------------------------------------------------------- __________ I believe that the current draft is ready for | YES | | submission to SC22 for its first CD ballot |_____|____| with comments I am assuming that there will be the possibility to fix all the formatting problems at this first go round of a CD ballot. (signed) ...Jeanne Adams........... (date) ...January 23, 1997....... ---------------------------------------------------------------------------- I believe that the current draft is ready for | | NO | submission to SC22 for its first CD ballot |_____|____| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. 1) Replace the text with that submitted by lrr. The lrr proposal is in keeping with existing practice, and meets more of the details of the user requests which motivate this work. Assuming (1) isn't implemented: 2) "ISO/IEC 1539 is an auxiliary standard to ISO/IEC 1539" I know we've gone around in circles on this for years, but I thought that once we'd gone to multiparts of a single standard that the term "auxiliary" was effectively meaningless. If not, the text should make clear what the term means in the formal ISO context. 3) "Coco execution is a sequence, in time, of actions specified by the coco directives. The actions are performed in the order that the directives appear. The result is conceptually a sequence of lines that is identical" I was unaware that we wrote standards specifying the "time" of actions. I thought we restricted ourselves to something along the lines of observable sequences (I'd just say sequence, but we usually leave room for optimization ; not that I think we need that latitude in this area). 4) note cc6.4, it seems that a processor can essentially do anything; what is the utility of this note? If the goal is to specify that if a file is produced, how the FALSE blocks should be written, it should say so more clearly. 5) "processor-dependent manner. Execution of a coco ERROR directive does not halt coco execution." Sounds more like what the English word "WARNING" usually means. STOP seems to be used for "fatal error". So I take it the intended idiom is for careful programmers to use "ERROR" to produce messages, and STOP to halt processing. If so, "ERROR" is really more of a generic coco PRINT statement, isn't it? If so, the name "ERROR" seems awkward in the extreme. 6) The same users that have asked for conditional compilation nearly always ask for macro expansion. This proposal is defective in addressing the clearly articulated user request. 7) "from the coco program. A processor may allow many coco-set-options." I don't understand, is this saying that a processor *may* allow for several different mechanisms to propagate options into coco processing or that a processor may allow more than one value to be set (if the latter, doesn't that have the effect of only allowing users to set a single option if they have any plans for portability?). I would not be surprised if a close examination by the committee (or a serious public review) revealed other shortcomings. (signed) Keith Bierman (date) 1/23/97 ---------------------------------------------------------------------------- __________ I believe that the current draft is ready for | YES | NO | submission to SC22 for its first CD ballot |_____|__X_| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. This is a very weak "no". In view of the controversy over the coco approach versus the fpp approach N1243 should be more assertive in demonstrating its advantages. Neither of its examples in annex CCA relate to its rationale. One of the main themes as Fortran has evolved since 1966 has been the way in which the programmer has been able to express his intentions more directly, without using artificial devices. If we want block comments, less us have them explicitly, not in this unnatural way. I found Example 2 unconvincing in the context of program development, acceptable in the context of long-term program maintenance. If other people had the same problem, maybe there should be a clarification somewhere. Where Coco comes into its own is to allow the presence in a source file of statements which would cause errors if passed on to the compiler on the current system; it would be advantageous to have such an example, even if the output file is not itself standard-conforming. (signed) ....D.T.Muxworthy......... (date) ....4.February.1997....... ---------------------------------------------------------------------------- _____ I believe that the current draft is ready for | YES | submission to SC22 for its first CD ballot |_____| This vote is a YES with the comment that I agree with most of the editorial suggestions that are being made. This document, like Part 1 or a diamond, is perfect depending on how closely you look at it. Obviously, the closer one looks, the more likely an imperfection presents itself. David Epstein Imagine1, Inc. 1997, Feb. 4th ---------------------------------------------------------------------------- ____ I believe that the current draft is ready for | NO | submission to SC22 for its first CD ballot |____| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. 1. There is no support for macro definition and expansion 2. The proposal does not standardize the existing practice that has already been established by use of cpp. (signed) Reva Sacks Hewlett-Packard (date) 2/4/97 ---------------------------------------------------------------------------- __________ I believe that the current draft is ready for | YES | NO | submission to SC22 for its first CD ballot |_____|_xx_| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. (signed) Malcolm Cohen (date) 5th February 1997 1. Delete section "2. RATIONALE" or move it to an annex - I am unhappy with normative text appearing in a section named "Rationale". 2. Section 4.CC1.1 1st para says: "The compilation phase, which is described in part 1 of this standard, ..." IS 1539-1 describes no such thing. It "describes" the syntax and semantics (the form and meaning) of a Fortran program. No "compilation", no "phase", no "processing phase". Similarly, the COCO definition should describe the form and meaning of a coco program. (The meaning seems to be that the result of "coco execution" is a Fortran program or part thereof). Paragraph 3 is almost there but is too confused with its "sequence, in time" and "result is conceptually" phrases. I want to know what the result *is*, not "conceptually is". 3. 4.CC3.1 says "[digit-string is specified in part 1, R402 of this standard.]" (a) Normative text ought not to appear inside brackets of any kind. (b) "part 1" and "R402" are reversed. (c) Instead of saying "part 1 of this standard" it should say "IS 1539-1:1997 (E)". (d) "digit-string" should be "