>>>>> "chk" == Chuck Koelbel <[log in to unmask]> writes:

chk> Are you suggesting that elemental be allowed to be impure only if
chk> it is not used in a parallel context?

No, I just saying that elemental procedures combine two aspects which
could be separated: parallelism and `syntactic sugar'.  I find 

   call foo (bar, baz)

more readable than

   do j = 1, min (size (bar), size (baz))
     call foo (bar(j), baz(j))
   end do
 
even if foo has side effects.

chk> Or are you suggesting that the requirements of parallelism are
chk> trumped by something else (I guess user convenience)?

No, at all. (I conceded that point last week :-).  But user
convenience is important as well and should be supported as long as
other aspects are not disturbed.

Note that I'm not suggesting to remove `elemental implies pure', I'm
just suggesting to add `impure elemental' as another case.  It's too
late for the first alternative.

chk> This seems to be the same discussion as we had last week.

It's related, but the thrust is different.  Last week, I suggested to
allow ``a little bit of indeterminacy'' for output to unit=* and while
this wouldn't hurt me, I understand your objections and conceded the
point.

This time, I'm arguing that elemental can be useful (and
deterministic) even if impure.  That's more general and not confined
to I/O and debugging.

chk> If you are suggesting that the impure elemental can be used in a
chk> FORALL

certainly not!

chk> or array assignment context,

I might be tempted, but I could easily be convinced that it would be a
bad idea.

chk> then your interpretation amounts to serializing those parallel
chk> constructs.  Depending on details of how this is declared, that
chk> serialization might be for all array assignments, for array
chk> assignments that call elemental functions, or for array assignments
chk> that call impure elementals.  This seems to defeat the purpose of
chk> array constructs; I'd advise against it.

I'm not an expert on (no pun indented) side effects in standard
documents.  If `impure elemental' had these side effects, then it is a
bad idea, but I don't see how.  But one should exclude array
assignments to be on the safe side.

chk> Is there something wrong with debugging the elemental function as
chk> a "normal" function?

If the function is simple enough that it can be debugged once and for
all: no.  But if I want to tune the performance of some adaptive
algorithm in `real life' applications, I have to rewrite the upper
layers of the libraries if I insert some `print *'s in the lower
layers.  This is something that I can live with (I have to keep a
Fortran90 version around, anyway), but impure elemental procedures
would make the quartet ``impure, pure, impure elemental, pure
elemental'' complete.

-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- [log in to unmask]
http://crunch.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%