From david@imagine1.com Sat Oct 26 04:55:22 1996 Received: from kitsune.swcp.com (kitsune.swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id EAA01964 for ; Sat, 26 Oct 1996 04:55:10 +0100 Received: from ppp117.swcp.com (ppp117.swcp.com [204.134.0.227]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id VAA23804 for ; Fri, 25 Oct 1996 21:54:59 -0600 Date: Fri, 25 Oct 1996 21:54:59 -0600 Message-Id: <199610260354.VAA23804@kitsune.swcp.com> X-Sender: evt@swcp.com (Unverified) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_846301900==_" To: sc22wg5 From: david@imagine1.com (David Epstein) Subject: Replies to N1192 ballot comments X-Mailer: X-Attachments: C:\DE\WG5\COCO\BALLOTWG.TXT; --=====================_846301900==_ Content-Type: text/plain; charset="us-ascii" Mallory, Please give this an X3J3 paper number. I will bring printouts to LasVegas. Thanks, David ------------------------------- --=====================_846301900==_ Content-Type: text/plain; charset="us-ascii" To: X3J3 From: David Epstein Subject: Replies to N1192 ballot comments Thanks to all that sent comments along with their vote on N1192. Below is a copy of the note from Miles (with the comments on N1192) with replies from the Project Editor on lines that follow ##P.E.Reply> Those that see a "No comment" reply will need to let me know if you were expecting a reply from the Project Editor. Note that replies to private email from Henry Zongaro and John Reid are in other papers. Please also note that a some responses ask for guidance from X3J3, SC22WG5 and the CoCo email development body. One final note of thanks; to Malcolm for suggesting CCR402 in place of R402 as the below responses could lead to some confusion. I am using the N1192 rules below, but have changed the rules in N1192r1 to the suggested CCRsnn which will simplify future communication. As well, the sections are numbered CCs. David ----------------- Comments on N1192 ------------------------------------- Accompanying a YES vote: ======================== However, the document should be formatted before submission to SC22. ##P.E.Reply> ISO formatting in progress. The following editorial error should be corrected: In R301, "coco-char-literal-constant" is missing. ##P.E.Reply> ## No. ## This is not an editorial error. The coco-char-literal-constant is ## only allowed in the ??ERROR directive (R701, R702) and is not ## allowed in a coco expression (R502). Accompanying a NO vote: ======================= 1. Technical comments: Reid ---- The document is quite obviously not ready. It is not properly formatted, it contains draft text of the form: [A name is specified in part 1, section x.y of this standard.] and its contains invalid Fortran such as PURE FUNCTION GET_RABBIT_WEIGHT(A_RABBIT) RESULT(WEIGHT) ##P.E.Reply> ## Yes. ## ISO formatting in progress. ## Other comments have been fixed. ## For replies to private email from John Reid, please see ## paper X3J3/96-xyz. Quite ironic that I don't have a paper ## number for it yet :) Maine ----- Whereas I concur with the general direction of the draft, I believe that it has had insufficient time for refinement in its current form. Until the Dresden meeting, it was not yet even decided which of the major alternatives ("fortran-like" vs "cpp-like") was preferred. Also, the "fortran-like" alternative selected recently underwent major prunning. Again, whereas I agreed with that pruning (and even had a part in suggesting it), it was a major change adopted relatively late in the process. It is typical of human nature (well, mine anyway) that when several proposals are on the table, they do not get as careful a review as when the one selected proposal is being refined. We have just now passed the stage of selecting among the proposals. Whereas there has of course, been substantial refinement of the proposals during this process, it is now time to do the final refinement. There is always a desire and need to progress the work as rapidly as feasable, but I see no unusual urgency that justifies skipping the final refinement steps for CoCo. The above comments are more procedural than about specific technical points. I have not spent sufficient time reviewing the technical content of the document in its current form, and I doubt that I am alone in that. ##P.E.Reply> ## No comment. Meissner -------- The general direction of the project is satisfactory. However, additional exposure to the Fortran user community, for technical review as well as further editorial refinement, is needed. ##P.E.Reply> ## No comment. Hendrickson ----------- The document needs further technical review. I have no concerns with the direction and do not know of any serious problems. It just hasn't had enough review in its final form. ##P.E.Reply> ## No comment. Whitlock -------- I believe that the document needs further technical review. I agree with the chosen direction but it just hasn't had enough review in this form to be final. ##P.E.Reply> ## No comment. Muxworthy --------- General: WG5 decided only at its last meeting that the CoCo approach was preferable to the fpp approach and N1192 was seen in its present form only at that meeting. History indicates that a thorough review by WG5 is likely to reveal the need for corrections and improvements which are far easier to make before the document is submitted to SC22. Editorial: - N1192 is not formatted or styled to ISO conventions. ##P.E.Reply> ISO formatting in progress. - N1192 is incomplete (numerous references to x.y for example). - Text should not be reproduced from a Sun manual; the text should be rewritten and the reference removed. - The description of the STOP directive (section 7) should be replaced by more formal language. - There is no definition of "rep-char" (used at N1192 R305, defined at Part 1 section 4.3.2.1). - In rule R503, "primary" should be "coco-primary". ##P.E.Reply> ## Yes. ## These have been fixed. Terminology: - "1539" should be "1539-1" throughout. ##P.E.Reply> ## Unclear. ## It appears to me that only the final references in 3. GENERAL- ## 1. Scope and 2. Normative References need to be changed as the ## others state "this part of IOS/IEC 1539". ## I am not sure that even these two references need to be changed. ## If I recall correctly, Part 2 refers to 1539 and not to 1539-1. ## I made this change but would like to be sure that this change ## is needed. - Although it would be absurd to change the word "compilation" to "processing" throughout, for consistency with Part 1 the word "compiler" should be changed to "processor" (and related word forms) where this refers to processing the outcome of the initial selection done by coco. ##P.E.Reply> ## Yes. ## This has been fixed. Comments to the editor: - Why does the set option (Section 10) deal with only one variable? Example 2 in Annex A shows a possible need for two variables. ##P.E.Reply> ## Yes. ## The set option can handle more than one variable. ## The BNF is changed to make this clear. - What is the output file from Example 1 actually used for? ##P.E.Reply> ## No telling. One possibility is that it is used as the displayed ## source in a debugger. - I am slightly uncomfortable that the Level-x expressions do not relate to the same number expressions in Part 1 (1,2,3 <=> 2,4,5). Does this matter? ##P.E.Reply> ## Yes it matters that you are slightly uncomfortable :) I have tried ## both methods of numbering and the current method is more clear. Morgan ------ The document clearly requires editorial corrections. ##P.E.Reply> ## No comment. Zongaro ------- - I feel that the CoCo facility is incomplete without a macro expansion facility. ##P.E.Reply> ## Noted. - I have many technical problems with N1192 (which I will forward to the project editor separately). ##P.E.Reply> ## For replies to private email from Henry Zongaro, please see ## paper X3J3/96-xyz. Cohen ----- N1192 No - the document is not ready. It needs a thorough technical review, and lots of editing to make it look like a new part of the standard. Some quick points from a cursory glance: - The BNF rules are named such that they can be confused with the ones in 1539-1 (I suggest something like R3.402, or CCR402, etc.). This is particularly pertinent since the BNF terms et al are used but not defined by N1192 (intending to import them from 1539-1). ##P.E.Reply> ## Yes. ## The rule numbers now look like CCR402. - Lots of "section x.y" references. - Initialization expression semantics are imported from 1539-1, but I cannot see how these can be applied to CoCo variables. Text is needed to define a CoCo-initialization-expr, since otherwise the entities allowed by R512 include Fortran PARAMETERs (which I do not expect CoCo to be able to evaluate) and exclude CoCo PARAMETERs. ##P.E.Reply> ## Yes. ## These have been fixed. - According to 3.2.2, any line that does not begin with "??" is a CoCo comment line. Seems unfortunate for the user program. ##P.E.Reply> ## No. ## Why is this unfortunate? A "CoCo comment line" is not a Part-1 ## "comment line". We have no idea if the CoCo comment lines are ## valid Fortran source, C++ source, or other text. - 6.0 talks about "execution" of a CoCo program, seeming to mean its processing to produce a Fortran program. I find this model of what is going on very difficult to understand or explain. ##P.E.Reply> ## Unclear. ## I am not sure if "processing" CoCo directives will be more clear than ## executing CoCo directives. I will ask X3J3 and anybody reading this ## note for input. Input? - There is not enough description of what is going on. ##P.E.Reply> ## Unclear. ## Could you be more specific? Would more examples have helped? - IMO a better model would be to include the entire program text as being part of the "CoCo program", this CoCo program is then processed according to its directives to produce a Fortran program for interpretation by 1539-1. ##P.E.Reply> ## Unclear. ## We do not know that the directives will produce a Fortran program. I expect that a lot more would come from a further review, but these are sufficient reasons to vote No. Ellis ----- There are a considerable number of editorial corrections required before the document conforms to ISO Directives. Moreover, as others have pointed out, there appear to be a substantial number of possible technical errors and/or ambiguities. I would be unhappy for this document to be forwarded to SC22 without further, detailed, technical review by WG5 and X3J3. ##P.E.Reply> ## No comment. 2. Procedural comments: Wagener/US ---------- Our parent committee had asked us to provide a recommended US position on this issue, on the assumption that it will come up at the SC22 plenary next month. The TAG voted to recommend approval of splitting the work item to form Part 3 but to disapprove adopting N1192 as the content of Part 3 at this time. [Convenor's comment: there was never any suggestion that it should be adopted at the Plenary; that is NEVER done as far as I am aware. The only proposals appropriate for the Plenary were the splitting of the Work Item, appointing of a Project Editor, and obtaining approval for simultaneous registration and approval ballots; these actions were all approved by the Plenary.] The main reason is that the US believes that the alternatives did not receive equal consideration in Dresden (e.g., comparable-style papers were not in the premeeting; papers on both approaches were not available during much of the discussion on this topic), and that due process therefore requires further consideration of the alternatives. Please record this NO vote as a US country vote (I will support the TAG, so also record my personal vote the same); for the US to vote YES on the content of Part 3, there will need to be a "balanced" consideration by WG5 of the alternatives. ##P.E.Reply> ## No comment. Bierman ------- Even if we really want to go down this path, COCO as currently written doesn't have features that experience has taught us customers *require* (e.g. macro expansion). So the draft is, at best, incomplete. Of course, I still maintain that we ought not do this at all (having researched the topic for the last year or so, on and off) because: * preprocessors/conditional compilation does not solve the portability problem(s), instead they paper over such problems. * Complicate the programming environment (debuggers, browsers etc.) * Complicate the compilation system (interferes with program database/whole program compilation, various acceleration schemes) * Newer languages depreciate their use (e.g. C++) or avoid them entirely (e.g. Java). Experience has taught us that they are an inappropriate solution. If we are to do it anyway, the imperative of Standardization is to cannonize existing practice. So we ought to use an "fpp" approach * Cannonize most prevalent existing practice * Remove worst warts of "cpp" as a Fortran processor * Extensive usability testing resulted in keeping more cpp than expected. Standardization of "coco" will have the unfortunate effect of creating *more* dialects of preprocessor, not fewer. Opposite the effect Standardization is supposed to produce. This comes about because: * History suggests that old preprocessors don't get abandoned. Any large project that uses one now, will continue to use the same one indefinitely. * Vendors have to continue to support what they have now. Virtually all Unix and Unix style vendors support cpp now. * Unless a miracle occurs, some vendors will implement and integrate COCO at different rates. Thus each user will have to choose between fully integrated "c/fpp" and user-hosted or partially supported COCO. Increasing the number of dialects of preprocessor will likely erode confidence in ISO standards in general, Fortran standards, and most particularly parts of the standard other than -1. In addition, vendors (and to a lessor extent users) will be diverted from working on more important things (e.g. f95, performance, programming environment work, etc.) which cannot be good for the future of Fortran as a viable environment. ##P.E.Reply> ## No comment. Adams ----- There are already enough preprocessors available for compilers. It will complicate portability problems for Fortran. I believe this should NOT become part of Fortran, it is not a language feature per se. ##P.E.Reply> ## No comment. North ----- I am supporting the USTAG position on this item. See comments by Jerrold Wagener in his vote. ##P.E.Reply> ## No comment. ------------------------- end of comments ----------------------------- --=====================_846301900==_--