Prev: Public review - CRITICAL and BLOCK
Next: Public review - Submodules
From: James Giles on 5 Jul 2008 02:40
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.
The example in the document is:

impure elemental function accumulate (a,sum)
real :: accumulate
real, intent(in) :: a
real, intent(inout) :: sum
sum = sum + a
accumulate = sum
end function accumulate

Where the call is:

real a(n), sum
:
sum = 0.0
a = accumulate (a,sum)

This seems simple enough. But suppose SUM was also declared
to be an array. The procedure would no longer "accumulate".
Nor would it generate any error messages or warnings. An
elemental is simply not a good way of accompishing such things
in the first place. You're trying to graft inappropriate
functionality in a place it doesn't fit well.

Now, if the procedure were declared:

function accumulate (a,s)
real, intent(inout) :: s
real, intent(in) :: a(:)
real :: accumulate(size(a))
s = sum(a)
accumulate = s
end function accumulate

The caller could be the same. The SUM argument could even be made
optional - it is certainly required to remain a scalar.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra


 | 
Pages: 1
Prev: Public review - CRITICAL and BLOCK
Next: Public review - Submodules