(j3.2006) reduction routine

[Van Snyder]

On Thu, 2010-05-20 at 07:44 -0700, Bill Long wrote:

> However, an alternate version would be to, in general, allow an actual
> argument be a generic name or the name of a operator (as in the first
> example above).  The cost is to add an attribute for the corresponding
> dummy argument
> 
> subroutine reduction (x, proc, ans)
> ...
>    procedure(),resolve(x) :: proc
> 
> 
> where the variables specified in the resolve() attribute can be other 
> dummy arguments.  An explicit interface would be required for such a 
> procedure.
> 
> If the actual argument is a procedure, then the resolve() attribute
> can be used to check the number and type of the arguments (assuming an
> interface for the actual argument is visible in the caller).

This is more elegant than Resolve(Operator(.myoper.),x,y) or
Operator(.myoper.)[x,y] as an actual argument

I prefer, however, that "proc" have explicit interface, making the
"resolve(x)" attribute redundant.  The actual argument could be a
generic identifier provided "reduction" has explicit interface where
it's invoked with a generic actual "proc" argument and the dummy "proc"
argument has explicit specific interface; resolution of the generic
actual argument to a specific procedure would be based on the
characteristics of the interface of its corresponding dummy argument.
This requires revision of C1235 and explanation in 12.5.2.9 (probably
p4) but very little new syntax is needed (R1223 needs to allow a
<generic-spec> such as "operator(.myplus.)" -- but probably not
<defined-io-generic-spec>).

Since we don't use characteristics of actual arguments that are
procedures (other than their procedureness) for generic resolution,
generic resolution of the actual "proc" argument can take place after
generic resolution of the procedure to which it is an argument.

If we want to allow characteristics of actual arguments that are generic
procedures to participate in generic resolution of the procedure to
which they are an argument, I suspect the "W" algorithm described in
"Functional Programming" by Field and Harrison would be needed.  This is
a complicated algorithm, and requiring it has been resisted in the past
(in the context of allowing function result characteristics to
participate in generic resolution).  It might be sufficiently
complicated that we would continue not to use characteristics of actual
arguments that are procedures for purposes of generic resolution.

Using explicit specific interface for generic resolution works also for
procedure pointer assignment:  If "proc" is a pointer with explicit
specific interface, something like

  procedure(its_interface), pointer :: proc
  proc => generic_identifier

would work.  This requires revision of C729 (and maybe C1220) and
explanation in 7.2.2.4 that generic resolution is done, but very little
new syntax is needed (R740 needs to allow a <generic-spec> such as
"operator(.myplus.)" -- but probably not <defined-io-generic-spec>).

This illustrates again that the concrete realization of projects is
frequently substantially different from the initially suggested
mechanisms.  Consider for example the difference between the
initially-suggested mechanism for CSV I/O and what was ultimately
provided, or the difference between parameterized modules and
macros, ....

As difficult and tedious as it is, design by committee is once again
demonstrated to be better than design by an individual.