From owner-sc22wg5@dkuug.dk Sat Jun 14 01:12:25 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5DNCPf4085235 for sc22wg5-domo; Sat, 14 Jun 2003 01:12:25 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5DNAwEc085219 for ; Sat, 14 Jun 2003 01:12:20 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Fri, 13 Jun 2003 16:08:21 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Fri, 13 Jun 2003 16:10:51 -0700 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.8/8.12.5) with ESMTP id h5DNAtnl009874 for ; Fri, 13 Jun 2003 16:10:55 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h5DNAtdk009870; Fri, 13 Jun 2003 16:10:55 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16106.23039.304303.588316@altair.dfrc.nasa.gov> Date: Fri, 13 Jun 2003 16:10:55 -0700 To: sc22wg5@dkuug.dk Subject: Type-spec X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Here's a draft of a paper for Dresden. John, please do not yet give this a number or put it on the server. This is just a draft. I'd like the opportunity for some more feedback before making it real (or even double precision). A few people have batted around the main points, but this is my first attempt at the actual edits. ISO/IEC JTC1/SC22/WG5 N???? Type-spec Richard Maine The examples in 8.1.5.3 do not agree with the bnf for the select type construct. The examples have statements like CLASS IS (POINT) TYPE IS (POINT_3D) According to the bnf, these should be CLASS IS (TYPE(POINT)) TYPE IS (TYPE(POINT_3D)) This paper proposes that the bnf be fixed to correctly reflect the syntax shown in the examples. It also proposes to correspondingly change the bnf syntax for explicitly typed array constructors and explicitly typed allocate statements. I. Why this change instead of some other? I believe that the examples, rather than the bnf, reflect what was the intent of the committee. The bnf version sounds wordy and either redundant (type is type) or contradictory (class is type). I believe that a lot more people studied the syntax of the examples than traced through the syntax of the bnf (if they had really traced through the bnf syntax, I'd have expected them to notice that the examples didn't agree with it). As additional evidence, I note that papers like N1522 (and all its predecessors) use syntax like that of the examples instead of following the bnf. Once we introduce this syntax into the bnf, I believe it is both simpler and more consistent to use it in two other places that currently derive from the same bnf, but could just as well use the simpler form. Those places are explicitly typed allocate statements and explicity typed array constructors. These places are all new to f2k, so there are no compatibility issues. The draft has no examples of explicit typing for allocate statements or array constructors. (Perhaps it should, but that's a separate question.) The only place where we need the long-winded form that includes TYPE() is in , which is a different branch of the syntax tree for other reasons anyway. II. Important f90/f95 interp question I think that C414 was intended to also exclude the name doubleprecision. Otherwise I'm not sure what it achieves. If doubleprecision is allowed as a derived type name, then the syntax of the examples has an ambiguity (intrinsic keywords do not "go away" when there is some other entity with the same name). The edits below include what I think is a clarification of this. If people think this is a change instead of a clarification, then we'd probably need to list that as an f90/f95 incompatibility. III. Incorporated editorial improvement Introducing this syntax into the bnf facilitates an overdue minor organizational improvement. We can cleanly separate the bnf for type specification from that of object declaration. Currently, it is a bit odd that the syntax for a type specification is mixed in with the section on object declaration, even though parts of it have nothing to do with object declaration. We will move the bnf for type specification into...surprise... the section talking about types. The fact that this eliminates a bunch of forward references from chapter 4 into chapter 5 gives an extra hint that this is where it belonged all along. This also eliminates a much duplication between 4.5 and 5.1.1. This move isn't required. We could keep all the bnf where it currently is in chapter 5, but I think this an editorial improvement. If a majority thinks otherwise, that question is separarable (but my proposed edits would need revision). IV. Edits {Seems like a good place for this - right after we've introduced intrinsic and derived types, and before any of what used to be forward references to this concept. This first edit is the one where the syntax change in the definition of is.} [33:8+] Insert A type is specified in several contexts by a <>. R400a <> <> C400a (R400a) The shall not specify an abstract type (4.5.6). [34:15] "5.1" -> "4.4" {We are moving that material} {And where we introduce the intrinsic types...} [35:27+] Delete [69:16-22] (R503) and move all but the last line of it to here as R401a, renaming it to . Move [70:21] (R507) to here as R401b. Move [71:20-21] (C526) to here, changing (R503) to (R401a) {This would probably be better referencing 401b instead of 401a, but I'll leave that aspect as is to minimize the number of changes to question.} [36:7], [38:1,2], [39:10], [40:15], [42:23] "(R503)" -> "(R401a)" (6 times) [43:10-11] Replace para with "The type specifier for a derived type uses the name of the type (R450)." {The phrase "the data entity" in several places is confusing. We aren't necessarily talking about any particular data entity, or multiple ones might be relevant, depending on context. In this section we are just talking about what type is specified, so we'll say that. The relationship of types to entities is discussed elsewhere and is just a confusing irrelevancy here. This edit is not mandatory; it is a separable question.} [36:8-9], [38:4,5], [39:13], [40:16-17], [42:24-25] "the data entity is of type" -> "the type specified is" (6x) {Replacement for material that will be deleted from chapter 5.} [38:6] After "(0.0D0)." insert "The type specified by REAL(KIND(0.0D0)) is the same as the one specified by DOUBLE PRECISION." {Character declarations are messier than the other intrinsic type declarations. It takes a substantial subclause in chapter 5 to give all its details. Mostly just copy that subclause to chapter 4. It has enough references to things all over the document that it fits about as well (or poorly) either place, but once we move the other stuff, this would look pretty lonely in chapter 5.} [40:14+] Insert heading "4.4.4.0a Character type specifier" [40:17+] Move [74:1]-[75:2] to here, after changing the "" at [74:30] to "". {Much of the [74:30-35] para is about , which our new definition of excludes; this change gets both cases, as we need it to.} [40:17++] Move Note 5.5 (pg 75) to here, changing "declaration statements" -> "specifiers" and deleting the s ("A" in the first example, "B, C*20" in the second). [40:17+++] Insert heading "4.4.4.0b Character literal constant" {Make sure to include doubleprecision. If people want to be even more explicit, we could specifically mention doubleprecision either in the normative text or as a note.} [44:2] "the name" -> "a type keyword". {Now handle the cases where we need the TYPE().} [69:9] replace line with "R502 <> <> TYPE() {Notes should be helpful instead of misleadingly incomplete.} [69:Note 5.2] before "or" insert ", a SELECT TYPE statement," {Above edits removed R503 from here. For C503 to still apply to all the same cases, we basically need 2 copies of it (or one copy that refers to 2 bnf rules). One copy was added above as C400a. The other copy stays here with some changes. Another paper makes the 4.5.3 xref more sesible.} [69:23] "(R503) The " -> "(R502) The TYPE()" [73:3] "Type specifiers" -> "Declaration type specifiers" [73:4] "<>" -> "" {Much of 5.1.1.1 to 5.1.1.6 already duplicated material in chapter 4. The parts that weren't already in chapter 4 have been added above.} [73:7]-[75:8] Delete sections 5.1.1.1 to 5.1.1.6, replacing them with the sentence "An in a type declaration statement is used to declare entities of intrinsic type." {The parts of [75:11-15] that make any sense are already in 4.5. The "If the contains a " part makes no sense because the isn't optional.} [75:11-15] Delete this para. {There are no edits needed in chapter 8; the above edits make be the right thing.} -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain