J3/03-147 To: J3 From: Malcolm Cohen Subject: Problem with defined assignment Date: 14th March 2003 1. Introduction [142:15-16] says apropos of the defined assignment statement x1 = x2, "The types of x1 and x2 shall not both be numeric ..." This has an obvious flaw in that it fails to limit this requirement to when x1 and x2 have conformant ranks. But there is worse to come... This is not effective in preventing one from defining such an assignment (e.g. via an ASSIGNMENT(=) interface block) as it places no restriction on the dummy arguments (d1 and d2) of the assignment subroutine. So we are left with 16.2.3, in particular the second sentence thereof, to prevent overriding intrinsic assignment of numerics etc. But given the initial sentence of 7.4.1.2 ([139:4-5]) "An intrinsic assignment statement is an assignment statement that is not a defined assignment..." the second sentence of 16.2.3 is ineffective as when you do the "defined assignment" the intrinsic one disappears and so there is no conflict. (Or if you don't think the intrinsic one disappears, then we've managed to lose the ability to override intrinsic assignment for derived types.) Some of these problems are new to the F2000 wording, some of them apply to F95 as well. 2. Discussion - defined assignments It is unclear what the intent of [142:15-16] really is. The only conceivable and reasonable intent is surely to prevent the user from overriding intrinsic assignment (other than for derived types) but (a) it is formulated wrongly for this task (b) it is in the wrong place - if we want to place requirements on defining assignment the right place is 12.3.2.1.2 (Defined assignments) where all the other requirements for it are. Moreover, these requirements are duplicated in 16.2.3 (second sentence) except that the 16.2.3 version makes no exception for derived types. Given the need for a derived type exception, it would seem easier to place the restrictions in 12.3.2.1.2 and to remove the incorrect duplication in 16.2.3. This is a prime example of "say it twice => it is wrong in both places". 3. Discussion - defined operations These are only actually restricted in one place - the second sentence of 16.2.3 - though the restrictions are stated in a second place: at [122:4-5] (for monadic ops) and [122:23-25] (for dyadic ops). I say "only restricted in one place" because the words in the other place(s) use the verb to be ("is") not the verb of requirement ("shall be"). Unlike defined assignment, there is no facility to override intrinsic operations and so 16.2.3 would seem to be technically ok. Again unlike defined assignment, the text in [122:23-25] mentions the need for both type and rank conformance, so that too would seem to be ok. I'll note in passing that again, the "requirements" are on the operands (x1 and x2 in "x1 .op. x2") not the dummy arguments of the function. So apart from the lack of use of "shall", these sentences are more descriptive than specificative. OTOH, I fail to see what is gained by putting (pseudo) requirements on x1 and x2 when it's supposed to apply to defining the operation in the first place. Anyway, like defined assignment, it would seem to be more appropriate (a) to only say this thing once! (b) to put requirements on defined operations in 12.3.2.1.1 (Defined operations). Some might think that the descriptive stuff is useful; I take the contrary view that it immediately raises the question "what if this ``is'' is not satisfied by the defined operation - what happens then? - is the interface block ignored? - or does something else happen? - or is there some actual restriction somewhere that stops it from arising?". So I think that it ought to be deleted whether the actual restriction is in ch12 or ch16. If we put these requirements into ch12 we can remove the problematic second sentence of 16.2.3 altogether. 4. Discussion - type-bound generics Type-bound generics for assignment and operations are defined to have the same requirements as specified in 12.3.2.1.1 and 12.3.2.1.2, so they will be handled properly iff the interface block generics are handled properly. 5. Edits to 02-007r3 These edits are neutral to the passage of UK comment TC1, except that the edit for [142:15-16] in this paper overrides the edit in the UK comment TC1 paper. [122:3] After "2" insert "or 2". [122:4-6] Delete "or that ..." until the end of the sentence. {Get rid of redundant description.} [122:22] After "2" insert "or 1 2". [122:23-25] Delete "or that ..." until the end of the sentence. {ditto} [142:15-16] Delete. {Text is multitudinously bad.} [258:11] After "operator" insert "and the types or ranks of the dummy arguments shall differ from those required for the intrinsic operation (7.1.2)" {Disallow overriding intrinsic operations.} [259:10] Split excessively long paragraph into two after "names." {This splits off the requirements and execution semantics from the introductory waffle.} [259:12] After "(IN)." insert "Either the second argument shall be an array whose rank differs from that of the first argument, the declared types of the arguments shall not conform as specified in Table 7.8, or the first argument shall be of derived type." {Disallow overriding intrinsic assignment except for derived types.} [397:16-18] Delete "If ... operand.". {This sentence is incorrect for assignment, and unnecessary for operations.} ===END===