From owner-sc22wg5@dkuug.dk Tue Jun 17 00:00:02 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5GM02Mn003233 for sc22wg5-domo; Tue, 17 Jun 2003 00:00:02 +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 h5GLxuEc003222 for ; Mon, 16 Jun 2003 23:59:58 +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; Mon, 16 Jun 2003 14:57:19 -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 ; Mon, 16 Jun 2003 14:59:50 -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 h5GLxrnl029325 for ; Mon, 16 Jun 2003 14:59:53 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h5GLxrHZ029321; Mon, 16 Jun 2003 14:59:53 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="914vC1hmio" Content-Transfer-Encoding: 7bit Message-Id: <16110.15833.760863.99947@altair.dfrc.nasa.gov> Date: Mon, 16 Jun 2003 14:59:53 -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 --914vC1hmio Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here's a revised draft of my type-spec paper, which John has assigned a number of N1540. This incorporates some minor comments received; the changes are all on the level of minor wording. This is still a draft so that further comments can be incorporated. Th erevisions here are minor enough that I suppose I might have procrastinated sending this out, but I get confused about the status if I have too many pending comments on too many papers, so I wanted to get the ones that I had agreed to incorporated. --914vC1hmio Content-Type: text/plain Content-Description: N1540.txt Content-Disposition: inline; filename="N1540.txt" Content-Transfer-Encoding: 7bit DRAFT 16 JUN 03 ISO/IEC JTC1/SC22/WG5 N1540 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. Note also, that the current bnf is new to the 03-007. The CD did not require the TYPE() bit of syntax. The bnf of SELECT TYPE was redone in the 03-007, apparently without this aspect of the difference being noticed. If it was noticed, the difference was not made sufficiently clear that anyone noticed that it made the examples incorrect. Thus this paper is proposing to fix a mistake introduced in the 03-007 rather than to change a long-established syntax. 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 [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). {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.} [34:15] "5.1" -> "4.4" {We are moving that material} [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] Delete this para. {No longer says anything useful.} [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) {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. The above edit is not mandatory; it is a separable question.} [38:6] After "(0.0D0)." insert "The type specified by REAL(KIND(0.0D0)) is the same as the one specified by DOUBLE PRECISION." {Replacement for material that will be deleted from 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" {Character declarations are messier than the other intrinsic type declarations. It takes a substantial subclause in chapter 5 to give all its details. The above edits 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.} [44:2] Before 'the same' add 'DOUBLEPRECISION or'. [69:9] replace line with "R502 <> <> TYPE() {Handle the cases where we need the TYPE().} [69:Note 5.2] before "or" insert ", a SELECT TYPE statement," {Notes should be helpful instead of misleadingly incomplete.} [69:23] "(R503) The " -> "(R502) The TYPE()" {Previous 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 sensible.} [73:3] "Type specifiers" -> "Declaration type specifiers" [73:4] "<>" -> "" [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." {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.} [75:11-15] Delete this para. {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.} {There are no edits needed in chapter 8; the above edits make be the right thing.} --914vC1hmio Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain --914vC1hmio--