(j3.2006) Public Comment J32035

[Jim Giles]

Aleksandar Donev wrote:
> Michael Ingrassia wrote:
>>                                                             08-249
>> To: J3
>> From: Michael Ingrassia
>> Subject: Public Comment J32035
>> Date: 2008 July 08
>> ----------------------------------------------------------------------
>> 
>> Commenter's Subject was "IMPURE ELEMENTALs"
>> 
>> I don't see the value in having IMPURE ELEMENTAL procedures.
>> There are no examples in the draft standard and the only
>> example in the document describing new features can be
>> rewritten without the procedure being ELEMENTAL at all.
> OK, so maybe the example is bad. Here are some uses that I find
> important (note that everyone on the committee was pretty much in
> agreement that impure was a good idea and in fact PURE was more or
> less useless and destroyed the utility of ELEMENTAL).

The only utility I ever saw for elemental was parallel operation.
It's the fact that almost no one implemented them that way that 
destroyed their utility.  Purity is (mostly) required for parallel
operation.  (Sure, there are some side-effects that don't require
any particular order and could be done in parallel - INTENT(OUT)
subroutine arguments are an example.)

> 1. It is awfully hard to debug PUREs (no WRITE!)
> 2. It is awfully hard for PUREs to record something about their
> execution (say a trace in a profiler), even if ordering does not
> matter 

Yes, purity in an imperative language is a hard thing to make good use
of.  I think it's always been a problem.

> 3. There can be no state-dependent ELEMENTALs, such as, notably,
> elemental random number generators.

Array-valued random number generators are already possible.  Why do
they need to be elemental?

I think all of what you want would be better accomodated by
allowing so-called "assumed rank arrays".  In the example case:

   function accumulate(a,s)
      real :: a(..), s
      real :: accumulate(shape(a))
      ...
   end function accumulate

(I leave out the code since the declarations are the part of interest.)
Here, the second argument is *required* to be a scalar (since the 
operation doesn't make sense otherwise).  That's a condition that
the impure elemental could not enforce.  In this code the accumulation 
could be in any order, not just array element order.  For other procedures
you could have several array arguments that *weren't* required to be 
the same shape, but *were* required to have related shapes (like:
argument V1 could be rank N, and argument V2 could be rank N+1,
with the requirement that the first N dimensions of V2 must have the
same shape as V1).  You can't do those things with elementals, pure
or not.

The "assumed rank" alternative would be both more legible and more
flexible.  And, I think they're likely to be more implementable.  The 
existing compilers probably have a lot of assumptions about elementals
that would be violated and cause major rewrites to permit impurity.

J. Giles