From J.Reid@letterbox.rl.ac.uk Fri Jan 19 16:44:40 1996 Received: from letterbox.rl.ac.uk (letterbox.rl.ac.uk [130.246.8.100]) by dkuug.dk (8.6.12/8.6.12) with SMTP id QAA17876 for ; Fri, 19 Jan 1996 16:44:29 +0100 Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Fri, 19 Jan 1996 15:43:55 +0000 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA16298; Fri, 19 Jan 96 15:44:59 GMT Date: Fri, 19 Jan 96 15:44:59 GMT From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9601191544.AA16298@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Re: UK substantive point 5 Malcolm and I have been reconsidering UK substantive point 5. This was deferred to X3J3 who rejected it. In view of the reasons given by X3J3, the comments of Kurt in WG5/S20, and a private email correspondence we have been having with Janice, we now propose the following edits to 007/R2. Our reasons are set out below. It would be particularly helpful if someone with HPF implementation experience could comment. EDITS: 214:6+. Add new constraint: Constraint: A dummy argument, or a subobject thereof, shall not appear in a except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, and the numeric inquiry functions (13.11.8). 214:17-18. Delete sentence: 'For ... expression.' 214:35-36. Delete sentence: 'For ... expression.' The UK point 5 was: > 5 Section 12.7.2 > 213:11-12. Replace sentence 'For ...' by > 'For a non-intrinsic procedure, an actual argument shall be scalar > if any specification depends on the value of the corresponding > dummy argument.' > > 213:18+. Add: > 'An example of an elemental procedure with an argument that is not > permitted to be an array is > > ELEMENTAL REAL FUNCTION F(A,N) > REAL A > INTEGER N ! The corresponding actual argument must be scalar > REAL WORKARRAY(N) > ... > END' > > Rationale: The present wording is far too restrictive. For example, it > does not permit > > ELEMENTAL REAL FUNCTION F(A) > REAL A > REAL (SELECTED_REAL_KIND(PRECISION(A)*2)) WORK > ... > END > > Also, it needs to apply to subroutines as well as functions. It was deferred to X3J3 who rejected it. The reason is given in X3J3/95-287: "Janice pointed out a case that the UK text missed, when the actual argument is a derived type with a component having the pointer attribute. One could write a specification expression which depended on the pointer association of a dummy argument's component, but not the value." A more fundamental problem was pointed out by Kurt in WG5/S20. Kurt notes that the restriction seems to be intended to aid optimisation; in particular: "is appears that many implementation are planned in which arrays are presented to the call interface and looping is done inside the procedure to reduce the call overhead. The restriction in question is intended to cover procedures such as the following:" ELEMENTAL REAL FUNCTION F1(N1) REAL WORKARRAY(N1) ... "If N1 is allowed to be different for each element position being computed, then the allocation and deallocation of WORKARRAY must take place within the loop. If N1 is assured to be the same for all the elements being computed, then the same storage can be reused and the allocation and deallocation moved out of the loop, reducing overhead." [MJC] Presumably the optimisation of passing the whole array into a single call would be applied transitively - one would not expect that e.g. calling TANH on an array was less efficient in an ELEMENTAL procedure! Kurt seemed to think of this as a separate optimisation, e.g.: Another useful optimisation is for an elemental procedure to take advantage of the elemental nature of any operators it uses. For example, in ELEMENTAL FUNCTION G(X) G = TANH(X+1) END the unoptimised approach would be to compute X+1 and then apply TANH one element at a time. If instead we compute the entire array of X+1 values and then invoke TANH elementally to apply those values, we reduce the call overhead associated with TANH from one call per element to just one for the entire array passed to G." However, the house of cards falls down in the following example: ELEMENTAL FUNCTION F(N,X,Y,Z) !Interface for elemental used-defined function G F = G(N,X,Y,Z) END ELEMENTAL FUNCTION G(M,X,Y,Z) REAL WORKARRAY(M) ... END In the reference to G from F, N is notationally scalar so is allowed by the current restriction (on actual arguments associated with M). However, there is no corresponding restriction when calling F on actual arguments associated with N, so the user could pass it an array. Thus in the main program, the user can call F with arrays for N, X, Y and Z; thus effectively calling G with arrays for M, X, Y and Z. So the restriction does NOT stop the user from passing an array used as a specification expression in an elemental function - it just makes them write in an extra level of procedure calling! And the implementor's job is not any easier (than omitting the restriction) because with separate compilation (but perfectly matching interface blocks!) it cannot know, when compiling F, than G's last argument is nasty. But since it is legal code, the implementor must compile G so that it WILL accept an array for M!! Kurt's three options for handling this situation were: 1. Remove the restriction because it does not help anyone. 2. Impose the stronger restriction (that in an elemental procedure one cannot use the value of a dummy argument in a specification expression; as you note, Janice, one also must not be able to use the association status of a subobject of a dummy argument is a specification expression). 3. Ignore the problem and leave it as is (because the standard is not inconsistent, just unhelpful). We think Kurt's option 2 should be adopted.