Subject: forall, Andy Meltzer's update restrictions

From: "Rex Page" <[email-masked]>
Date: Thu, 25 Jun 92 15:29:48 -0500

> > 	"Any storage location which is updated by one forall-block 
> > 	 (in a function, subroutine, or assignment) may not be 
> > 	 updated or read by any other forall-block."
> > 
> 
> Uh, wouldn't that restriction also make this non-standard-conforming?
> 	FORALL ( I = 2:N-1 )
> 	  A(I) = A(I) * 2		! S1
> 	  B(I) = A(I-1) + A(I+1)	! S2
> 	END FORALL
> A(I) in S1 is read by S2 on different iterations...
> 

Andy says:
  Yes, this would be non-standard conforming.  In my not-too-careful reading
  of Marc's proposal I had missed that S1 completes before S2 starts.  If you
  take my restriction to consider only single statements within a FORALL loop
  at a time, it probably works.  But you're right, it has to be carefully 
  worded.

Well, shouldn't the following array assignments have the same effect?
And doesn't the forall violate your constraint?

    forall (i=2:n-1) A(i) = A(i-1) + A(i+1)
       and
    A(2:n-1) = A(1:n-2) + A(3:n)

  - Rex

---

From: [email-masked] (Andy Meltzer)
Date: Thu, 25 Jun 92 16:34:30 CDT

>     A(2:n-1) = A(1:n-2) + A(3:n)

No, the effect is different.  In Chuck's example B ends up with the "final"
write.  In yours the final value is in A.   

							Andy

---

From: "Rex Page" <[email-masked]>
Date: Fri, 26 Jun 92 07:11:17 -0500

>     A(2:n-1) = A(1:n-2) + A(3:n)

Andy replied:

Sorry, Andy, I didn't say what I meant.
My point was that the two array assignments in my example have the same
effect as each other (not the same effect as your example), that they have
a desirable effect (one that we would want to retain), and that the forall
violates your constraint, even when reworded to consider only single
statements within a forall.

  - Rex