Subject: Re: Forall

From: [email-masked]
Date: Thu, 25 Jun 92 15:01:23 -0500

> From: John Merlin <[email-masked]>
> Date: Thu, 25 Jun 92 18:17:13 BST
> Subject: Re: Forall
> 
> >From [email-masked] Wed Jun 24 21:46:24 1992
> 
> > Case study:
> > 	FORALL ( I = 1 : N )
> > 	  IF ( A(I) < EPS ) THEN		! S0
> > 	    A(I) = 0.0				! S1
> > 	    B(I) = 0.0				! S2
> > 	  ELSE
> > 	    A(I) = (A(I-1) + A(I+1)) / 2	! S3
> > 	    B(I) = A(I) * 3			! S4
> > 	  END IF
> > 	END FORALL
> > ...
> 
> This seems to be a case for allowing conditional expressions (as in C)
> in forall-assignments, which is really what you want to express 
> in the above example.  (I proposed this once before in the context of
> alignment and distribution directives).  Using these, the above example
> without stmts S2 and S4 could be written:

I agree that this would be a better language design (well, I'd use a
less terse syntax than C).  However, we are trying to make minimal
changes to Fortran.  I think that leaves us with the options of
agreeing on a semantics for IF for the troublesome cases, agreeing on
restrictions to IF inside FORALL, or not allowing IF in FORALL at all.

> ...
> If you introduce the conditional expressions for this case, then
> the other case, where you want S3 to use the *new* values computed by
> S1, can be expressed with the IF construct using its normal meaning:
> 
>  	FORALL ( I = 1 : N )
>  	  IF ( A(I) < EPS ) THEN		! S0
>  	    A(I) = 0.0				! S1
>  	  ELSE
>  	    A(I) = (A(I-1) + A(I+1)) / 2	! S3
>  	  END IF
>  	END FORALL
> 
> Then you don't need to introduce a scalar WHERE construct within
> FORALL for this case, which I also think should be avoided on the
> same grounds as above.

The problem is, I'm unconvinced that this *is* the "normal" meaning of
IF.  My intuition says that reversing the sense of the condition and
exchanging the THEN and ELSE branches shouldn't change the meaning of
the IF; that's not true with the semantics here.

> 
>                     John.
> ...
> P.S.2:  I plan to input something about user-defined elemental 
> procedures soon.  It's just a matter of knuckling down to it!
> 

Glad to have the input.

	Chuck