Subject: Back to business

From: [email-masked]
Date: Thu, 16 Jul 1992 16:24:31 -0600

OK, I think I've caught up on the FORALL mail.  Just in time, too, since 
we need to get a draft together for the meeting next week.  Fortunately, 
I think there is now consensus on at least some of the major issues.  
(Unfortunately, I am not sure one of those issues is "Should there be a 
FORALL at all?" More on this later...)

I'll edit the current documents together to produce a draft based on the 
points below.  If you see a problem with anything here, feel free to 
sound off now (or tomorrow, when the draft will hopefully appear).

Areas of general agreement:

1. FORALL should be a generalized assignment statement, basically not 
much more powerful than (masked) array assignment.  This is not the right 
mechanism for introducing general MIMD control.

2. Single-statement FORALLs should have the SIMD semantics of Fortran 8X 
FORALL, CM Fortran FORALL, MasPar FORALL, etc.  (See below for 
restrictions on what statements can be FORALLized.)

3. Block FORALLs should contain only series of generalized assignment 
statements, that is ordinary assignment, array assignment, FORALL 
constructs, and WHERE constructs.  

[Side note: I no longer advocate extending WHERE to allow scalar masks; 
the MERGE function performs (almost everything) I want without requiring 
extensions.  The only thing that is still inconvenient is something like 
(faulty syntax coming up!)
	FORALL ( i = 1:n )
	  IF ( a(i) .ne. 0.0 ) THEN
	  	x(i) = 1.0
		y(i) = 1.0
	  ELSE
	    x(i) = 2.0
		y(i) = 2.0
	  ENDIF
	END FORALL
That is, multiple statements controlled by the same condition; writeable 
using MERGE, but lots of replicated conditions.]

4. Dave Loveman's scalarization seems to be correct.  Unless I missed 
something, Marc Snir's scalarization is equivalent to Dave's in the 
restricted cases described above.

5. Min-You's INDEPENDENT proposal has generated no comment, except for 
two renaming suggestions (BEGIN INDEPENDENT and BEGINDEPENDENT).  I've 
heard a few comments privately, however, that this is not sufficient, in 
particular that reductions are needed as well.

Major areas of disagreement:

I. Should FORALL be in HPF at all?  Alan Karp makes a good argument that 
it is not necessary.  I agree that anything expressible by FORALL can 
also be written using DO, array assignments, and (maybe) compiler 
directives.  However, comments on with Fortran 8X and CM Fortran indicate 
that users strongly support the expressiveness of FORALL.

For purposes of the draft, FORALL will definitely be included (else it 
would be an awfully short document!).  I think that user preferences 
should sway us toward including FORALL in full HPF.  In view of the 
controversy, however, I will include language to the effect that FORALL 
should not be in the subset.

II. Should functions in FORALL be restricted, and if so how?  The 
candidates are
	A. (Steele, Loveman and Snir proposals) Any function can be called, but 
	it cannot have side effects on the subscripts in the assignment 
	statement.  It appears that other side effects are allowed, but the 
	order of evaluation is undefined.  Am I reading that right?
	B. (Merlin, Page, and Cowie discussion) Introduce ELEMENTAL functions, 
	and only allow those to be called in FORALLs.  The two restrictions of 
	ELEMENTALs are (roughly) to enforce no side effects and to ensure that 
	the functions can be called without communication.
I suspect that others could cloud the issue with new proposals if they so 
chose.

For purposes of the draft, I will take a minimalist approach.  I'll 
eschew adding ELEMENTAL functions, but place more restrictions on the 
behavior of functions called from FORALL (essentially, that they can't 
have any side effects visible in other iterations).

Don't let this stop the discussion of ELEMENTAL.  I can be outvoted!  In 
fact, I'd support adding ELEMENTAL as an assertion to provide compiler 
information.

Time permitting, I'll also circulate a separate proposal recommending 
several other assertions along the lines of INDEPENDENT.  We can't agree 
on these before the next meeting, I'm sure.  However, I think we can 
treat them as a preliminary proposal for the meeting after that.

						Chuck