Subject: And now for something completely different (comments on July minutes!)

From: [email-masked]
Date: Mon, 31 Aug 1992 14:19:38 -0600

>From: John Merlin <[email-masked]>
>Date: Mon, 31 Aug 92 13:47:25 BST
>To: [email-masked]
>Subject: And now for something completely different (comments on July minutes!)
>
>Comments and questions on July HPFF minutes.
>--------------------------------------------
>
>Sorry to interject this into the fascinating discussion on Templates, 
>but since I wasn't present at the July HPFF meeting, here are my
>belated comments and questions on matters arising from the minutes.
>(BTW, thanks, Chuck, for your excellent and detailed minutes.  
>I reckon I've got almost as much out of reading them as I would have 
>done from actually attending the meeting!)
>
>I've posted this just to the 'hpff-distribute' group - though that's 
>probably wrong as some of these items relate to the 'forall' group - 
>on the assumption that interested parties read both groups and wouldn't 
>want to see the same thing twice.  If bits of it don't reach who they 
>should I'd be grateful if someone would forward them for me.  
>(BTW -- where should I post this -- I assume I can't post replies 
>directly to 'hpff'?).
>
>Anyway, here goes.

Hi, John

I've edited out the distribution parts of you message, and am forwarding
the rest to hpff-forall.  The suggested address for replying to any message
is the appropriate subgroup list (there's nothing to prevent you from
sending to "[email-masked]", but I don't recommend it unless the message is
really generally important!)

>> FORALL and INDEPENDENT
>> 
>>                                       ... There was some
>> discussion whether the evaluation of functions in right-hand
>> sides following these rules would be generally identical to
>> Fortran 90 array assignments. A consensus eventually
>> developed that there were two appropriate analogies: user
>> functions returning arrays, which are executed once, and
>> intrinsic elemental functions, which are executed once for
>> each element. The semantics given were consistent with
>> elemental functions, satisfying the group...
>
>I don't want to flog this issue to death, but the conditions on FORALL
>functions stated in the original proposals (viz, taken from later-on
>in the minutes):
>
>>      Function calls are allowed in FORALL subject to
>>        the following conditions:
>>        *  Side effects cannot affect values computed
>>           by the same statement in other
>>           instantiations
>>        *  Side effects cannot affect other
>>           subexpressions in the same statement on
>>           the same instantiation
>
>are *not* equivalent to elemental functions.  The latter have no
>side-effects whatever.  The above conditions allow side effects
>to variables not referenced by the statement in which the function
>is called, which can lead to non-determinism if the function is invoked 
>multiple times concurrently (e.g. multiple assignments, in any order, 
>to the same global variable).
>
>This is a convenient plug for Chuck's and my revised proposal for
>'pure procedures' for use in FORALL (which replaces the section on
>'ELEMENTAL Functions' in the draft document 'Tentative Proposal for 
>FORALL and INDEPENDENT', which had some technical problems), which 
>will be posted later today!
>
>
>>                                      ... David Loveman
>> pointed out that ...                    ...     ELEMENTAL
>> functions had been dropped from Fortran 90 for requiring too
>> much support from an already large language.
>
>I wasn't party to the F90 discussions so I don't know the
>basis for this claim, but I'm surprised.  As far as I can tell
>from considering the possibility of user-defined elemental functions
>in 'ADAPT', they require no extra mechanisms or support whatsoever -- 
>they appear to be simplicity itself to implement.
>
>
>>   Marina Chen began the discussion by asking, "What about
>> Alan Karp's comments?" ...
>>                   ... Karp's next criticism was that FORALL
>> is dangerous because statements in it have different
>> semantics. For example, the statement
>>           A(I) = A(I) + A(I-1)
>> has a markedly different affect inside DO and FORALL loops;
>> one is a prefix sum operation, while the other is a shift
>> and add.
>
>This seems to me to be a spurious argument.  The above statement can 
>have either meaning in a DO-loop, depending on whether the DO-loop stride 
>is positive or negative.
>
>If this argument has any validity all, it seems to be an argument
>against DO-loops and in favour of FORALL, as the interpretation
>of the statement in FORALL is independent of the FORALL stride, and is
>the same as for the unadorned statement (i.e. not in any constructs), 
>viz., use the old values on the rhs.
> 
>

>Best regards,
>       John.