From david@imagine1.com Mon Jan 22 05:09:43 1996 Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id FAA01212 for ; Mon, 22 Jan 1996 05:09:22 +0100 Received: from ppp42.swcp.com (ppp38.swcp.com [198.59.115.148]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id VAA13152; Sun, 21 Jan 1996 21:09:06 -0700 Date: Sun, 21 Jan 1996 21:09:06 -0700 Message-Id: <199601220409.VAA13152@kitsune.swcp.com> X-Sender: evt@swcp.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_822283829==_" To: sc22wg5-coco@ncsa.uiuc.edu From: david@imagine1.com (David L. Epstein) Subject: Straw vote: 16 item CoCo definition Cc: sc22wg5@dkuug.dk X-Mailer: X-Attachments: C:\DE\WG5\COCO\COCO1.TXT; --=====================_822283829==_ Content-Type: text/plain; charset="us-ascii" --=====================_822283829==_ Content-Type: text/plain; charset="us-ascii" Dear CoCo Development Body and Observers, (WG5, this is for your information. It gives you an idea where we are with the Fortran-like Conditional Compilation definition.) Here is a first cut at an "almost complete" conditional compilation definition. Imagine that the lexical tokens part (Section 3 of the Fortran standard) is to be decided later. This definition uses a '?' in the front of the CoCo directives. Also, we haven't discussed if these directives can be continued (or any of a number of other lexical topics.) We will look at all of these topics in a month or so. This is a Fortran-like, CoCo-only language. The intent of this definition is to narrow down the number of open topics before the Feb. 5th X3J3 meeting. The definition is not in standardese and is not meant to be a final definition. Recent decisions have paved the way for a minimal, usable, subset of Fortran. The majority votes and email appear to prefer this approach to either (a) extending (going beyond) Fortran or (b) keeping all of Fortran. For example, an extended ?INCLUDE was voted down as well as the ?CHARACTER type (?REAL, ?COMPLEX, kinds, POINTER, TARGET, etc.) Please vote and comment on this CoCo language. WG5 members that are not on the CoCo email reflector list can vote also. Thanks, David Imagine1 *** STRAW VOTE -- TIMING *** You have one week. Please vote before the end of Friday, 1996 Jan 26th. I will report the results after the weekend, on Monday, 1996 Jan 29th. This will give us one week of discussion before the X3J3 meeting. *** STRAW VOTE -- WHAT TO DO *** Send your vote to me (david@imagine1.com) or to the CoCo reflector. Below are 16 items (numbered #1 to #16.) Vote either YES or NO. A NO vote shall be accompanied by a list of numbers that you disagree with. Please comment on each item that accompanies a NO vote. Example votes follow (this is not my vote, simply examples): Example 1 I vote YES. Example 2 I vote NO: #1 I do not want the ?PRINT directive in the list. #2 I want to allow ?INTEGER and ?LOGICAL declarations outside a ?MODULE. My reasoning is that there are many single-user, single-file programs out there and they need not be forced to put all their CoCo variables into a CoCo module. #11 No ?PRINT directive. *** STRAW VOTE -- THE COCO LANGUAGE DEFINITION *** #1 Here is a list of all the conditional compilation directives. ? MODULE module-name ? END MODULE module-name ? USE module-name INCLUDE char-literal-constant ? INTEGER [,PARAMETER] :: name [=expr] [,name [=expr]] ... ? LOGICAL [,PARAMETER] :: name [=expr] [,name [=expr]] ... ? name = expr ? IF (expr) THEN ? ELSEIF (expr) THEN ? ELSE ? ENDIF ? PRINT *, [output-item-list] ? STOP [stop-code] #2 Here are the directive order rules. r1. The INCLUDE line can go anywhere except inside a CoCo module. r2. A CoCo module starts with a ?MODULE and ends with a matching ?ENDMODULE. r3. The body of a CoCo module consists of zero or more ?INTEGER or ?LOGICAL directives; no other CoCo directives are allowed inside a CoCo module. The INCLUDE line is not allowed inside a CoCo module. r4. The ?INTEGER and ?LOGICAL directives shall appear only in the body of a CoCo module. r5. A ?USE shall not appear in the body of a CoCo module. r6. A ?USE shall reference a CoCo module that has been previously seen. If a CoCo module appears in the same source text as any ?USE that references it, the CoCo module shall appear before this ?USE. r7. A CoCo IF construct starts with a ?IF and ends with a ?ENDIF. Optional ?ELSEIF directives can preceed an optional ?ELSE in the body of a CoCo IF construct. (Similar to the Fortran IF construct.) r8. The body of a CoCo IF construct cannot contain a ?MODULE, ?ENDMODULE, ?USE, ?INTEGER or ?LOGICAL directive. r9. An assignment directive shall be preceded by a ?USE, so that the name on the left of the '=' is available. The same holds for any name appearing in a ?IF, ?ELSEIF or ?PRINT. r10. A name shall be given a value before it is referenced. #3 ?MODULE module-name #4 ?END MODULE module-name NOTE: The word MODULE and the module-name are required. #5 ?USE module-name NOTE: There is no ONLY or renaming facility. #6 INCLUDE char-literal-constant If this line appears in a false branch of a CoCo IF construct, it is not expanded. #7 ? INTEGER [,PARAMETER] :: name [=expr] [,name [=expr]] ... NOTE: the '::' is required NOTE: the only names allowed in the expr are previously seen CoCo PARAMETERs. #8 ? LOGICAL [,PARAMETER] :: name [=expr] [,name [=expr]] ... same NOTEs as #7 #9 ? name = expr #10 ? IF (expr) THEN ? ELSEIF (expr) THEN ? ELSE ? ENDIF NOTE: there is no construct name available. #11 ? PRINT *, [output-item-list] where output-item-list is expr or char-literal-constant (not a substring) #12 ? STOP [stop-code] #13 Here is a list of what is allowed in a CoCo expr: o ( expr ) o integer constants o .true., .false. o +, -, *, / (not **) o ==, /=, <, >, <=, >= (not .eq., .ne., .gt., etc.) o .not., .and., .or., .eqv., .neqv. #14 If a name appears in more than one CoCo module, only one of these CoCo modules shall be used in the source text. NOTE: this is stronger than Fortran which allows the same name in more than one module as long is it is not referenced. The override value (see next item, #15) partially drives this item. #15 A name shall be given a value before it is referenced. This can be done three ways, (1) on the ?INTEGER or ?LOGICAL directive (2) on the ?assignment directive (3) on the command line An "override value" is a command line value. An override value will override the value specified on the ?INTEGER or ?LOGICAL directive (if any), but will not override the value specified on the ?assignment directive. An override value shall not be supplied for a name that has the PARAMETER attribute. #16 A CoCo module may appear in a ?USE directive more than once. Each appearance of a CoCo module in a ?USE reinitializes any values supplied on the ?INTEGER or ?LOGICAL directives. If an override value is supplied for a name in this module, the override value once again overrides the initial value supplied on the ?INTEGER or ?LOGICAL directive (if any). For example, the command line contains an override value of 3 for debug_level and .true. for debug ? module mod_debug ? integer :: debug_level = 0 ? logical :: debug ? endmodule mod_debug ? module mod_systems ? integer, parameter :: DOS = 1, UNIX = 2 ? integer :: system = UNIX ? endmodule mod_systems ? use mod_debug ? use mod_systems ? print *, debug_level, system ! outputs 3 2 ? if (debug .and. debug_level == 0) then ? debug_level = 2 ? elseif (debug) then ? debug_level = debug_level + 1 ? endif ? system = DOS ? print *, debug_level, system ! outputs 4 1 ? use mod_debug ? use mod_systems ? print *, debug_level, system ! outputs 3 2 --=====================_822283829==_--