(j3.2006) contradiction in CO_REDUCE

[John Reid]

Bill Long wrote:
>
> On Jan 16, 2014, at 3:14 PM, John Reid <John.Reid at stfc.ac.uk> wrote:
>
>>
>>
>> Bill Long wrote:
>>>
>>> Deepak from Univ of Houston pointed out a contradiction we have in the specification of CO_REDUCE.  We say that OPERATOR ?shall be a pure elemental function with two arguments...?.  But C1234 prohibits such a procedure as an actual argument. !!    We can fix this by changing the requirement for OPERATOR to ?shall be a pure function with two scalar argument??.
>>>
>>
>> Surely we want it to be elemental since SOURCE may be any array. Note
>> that SUM, MAX, MIN are elemental. How about adding this as an exception
>> on C1234:
>>
>
> But the compiler knows about SUM, MAX, MIN, and can make the appropriate accommodations if necessary.
>
>>
>> C1234 (R1223) A nonintrinsic elemental procedure shall not be used as an
>> actual argument except in an invocation of the intrinsic subroutine
>> CO_REDUCE.
>
> Except that there is a reason for the constraint in the first place, and I don?t see how CO_REDUCE is sufficiently special to ignore that.  If we require that OPERATOR have two scalar dummy arguments of the right type, then for an array SOURCE in a CO_REDUCE call,  the operation is just applied to elements.
>

I can't remember what the reason is. If we require the procedure to be 
elemental, there is nothing to stop a vendor calling it element by element.

I suppose the argument can also be turned on its head: taking out the 
elemental requirement does not prevent the user providing an elemental 
procedure and an optimizing compiler taking advantage of it.

John.