J3/03-219r1 As amended at J3 Meeting 165 (includes edit from 03-230). Date: 21 August 2003 To: J3 From: Michael Ingrassia Subject: Response to N1540 on type-spec Re: WG5/N1562 ISO/IEC JTC1/SC22/WG5 N1562 Michael Ingrassia This is a response to N1540 with subgroup comments interlarded. 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. [The paper] also proposes to correspondingly change the bnf syntax for explicitly typed array constructors and explicitly typed allocate statements. Subgroup agrees and notes this entails a TECHNICAL CHANGE. Assuming a declaration like TYPE(T(:,:)), POINTER :: P The syntax for array constructors changes from something like [ TYPE(T(10,20)) :: P ] to [ T(10,20) :: P ] and from ALLOCATE(TYPE(T(10,20))::P) to ALLOCATE(T(10,20)) :: P 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 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. Subgroup changed R401a to R401b in this edit: Move [71:20-21] (C526) to here, changing (R503) to (R401b) | Extra edit from the editor (see paper 03-230): | [71:20] Delete "in ". Subgroup changed this edit. [36:7], [38:1,2], [39:10], [40:15], [42:23] Delete "(R503)" (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.} Subgroup added additional edit. [38:5-6] Replace ", ... (0.0D0)." with ", the kind value is KIND(0.0D0) and the type specified is <>"." Subgroup deleted an edit here. {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.} Subgroup changed this edit. [75:4+4-5] Move these two code lines to [73:2+11+] (after COMPLEX). [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().} Subgroup modified the edit here. [69:Note 5.2] before "or" insert ", a SELECT TYPE construct," [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.} Subgroup added an edit. [75:20] Delete "or". Subgroup added this edit [125:32] LateX edit D5: Type specifier -> D5: Declaration type specifiers