(j3.2006) reduction routine

[Malcolm Cohen]

--------------------------------------------------
From: "Van Snyder" <Van.Snyder at jpl.nasa.gov>
Date: ?? 22?5?20? 3:04
To: "fortran standards email list for J3" <j3 at j3-fortran.org>
Subject: Re: (j3.2006) reduction routine

> This is one of the reasons that I proposed in 04-391r1 to provide a
> means to resolve a generic name without evaluating arguments of invoking
> the specific procedure to which it is resolved.

Which does not on the face of it solve the stated problem, viz.

> On Wed, 2010-05-19 at 08:06 -0700, Bill Long wrote:
>> Suppose you wanted to have an intrinsic that did a general reduction
>> operation, such as
>>
>> call reduction (array, operation, result)
>>
>> where there is an intrinsic or defined operation specified by the
>> 'operation' argument that is visible in the caller scope.

Note the word "intrinsic" here.

One could extend 04-391r1 to require vendor provision of (presumably unnamed) 
specific procedures for all intrinsic procedures and operations.  And 
assignment?  Defined i/o might be fun too.

I must admit that if we're going to start adding special forms, I'd make array 
reduction a special form too, I wouldn't make it use the general facility.

Viz
  Call reduction(X, .myoper., ans)
or even
  Reduce(X) To (ans) Using(.myoper.)
rather than
  Call reduction(X, Resolve(Operator(.myoper.),Y,Z),ans)
or
  Call reduction(X,".myoper.",ans)

(Aside: I don't know why reduction would be a subroutine instead of a function - 
the existing reductions being functions, there wouldn't appear to be anything in 
the way of making the general one a function.)

And when X is polymorphic, does RESOLVE return a special thingo that gets 
dynamically dispatched, or do we already have to look up X's dynamic type on the 
RESOLVE call?  This could be really exciting!

Anyway, I think that no special form is necessary - just have REDUCTION take a 
procedure argument, and apply the procedure.  The user can write his own 
function and have both genericity and dynamic dispatch applied within it should 
that be what he wishes.  It's hardly a significant burden on the user to write a 
few extra lines of code here.  I don't believe performance is an issue: we all 
know about inlining trivial functions when appropriate, and not having to invent 
the infrastructure for these special forms would give us more time to spend 
inlining anyway.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.