From david@imagine1.com  Fri Sep 20 06:19:21 1996
Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id GAA09627 for <sc22wg5@dkuug.dk>; Fri, 20 Sep 1996 06:19:18 +0200
Received: from ppp102.swcp.com (ppp102.swcp.com [204.134.0.212]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id WAA21186; Thu, 19 Sep 1996 22:19:07 -0600
Date: Thu, 19 Sep 1996 22:19:07 -0600
Message-Id: <199609200419.WAA21186@kitsune.swcp.com>
X-Sender: evt@swcp.com (Unverified)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Miles.Ellis@etrc.ox.ac.uk (Miles Ellis)
From: david@imagine1.com (David Epstein)
Subject: Re: (SC22WG5.1162) Review of N1192 - Conditional Compilation (Part 3)
Cc: sc22wg5 <sc22wg5@dkuug.dk>, sc22wg5-coco@ncsa.uiuc.edu
X-Mailer: <PC Eudora Version 1.4>

>                                                 _____
>I believe that N1192 is ready for submission    | YES |
>to SC22 for balloting as a Committee Draft      |_____|
>for Part 3 of the Fortran Standard              |     |
>                                                |_____|
>
>If NO, give reasons and suggested work to make the document suitable for
>submission to SC22:



{{{ A different note tells how to download a CoCo processor written
in standard Fortran.  David }}}

Although Miles recently mentioned avoiding YES with comments, I need
to make the following two comments:

 (1) A new PostScript version of N1192 was sent to Miles.  The previous
     version was not really formatted, and as John Reid pointed out,
     a Fortran statement was incorrectly split across lines.  Other
     than formatting, the only edits to N1192 are listed in the next 
     comment ...

 (2) The accurately formatted PostScript version of N1192 has updated
     edits for all references to Part 1 previously stating "x.y".

       For "name", change "x.y" to "3.2.1"

       For "Lexical token", change "x.y" to "3.2"

       Change "Object-name token" to "Object-name"
       For "Object-name", change "x.y" to "Section 5"

       For "mult-op", change "x.y" to "7.1.1.3"

       For "add-op", change "x.y" to "7.1.1.3"

       For "rel-op", change "x.y" to "7.1.1.5"

       For "not-op", change "x.y" to "7.1.1.6"

       For "and-op", change "x.y" to "7.1.1.6"

       For "or-op", change "x.y" to "7.1.1.6"

       For "equiv-op", change "x.y" to "7.1.1.6"

       For "Initialization expression", change "x.y" to "7.1.6.1"

These two items address the only comments I have seen so far on
the content of paper N1192.


This is not a country vote, but my own,

David