(j3.2006) reduction routine

[Van Snyder]

On Thu, 2010-05-20 at 13:19 -0700, Bill Long wrote:
> 
> Van Snyder wrote:
> > 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.
> 
> 
> I think this is missing a point, which perhaps I failed to make clear. 
> The resolve(x) attribute allows the generic resolution based on the 
> dynamic type of the actual argument corresponding to the dummy argument 
> X.

Sorry, I didn't get the combination of generic resolution and runtime
type dispatch from the original suggestion.

This is a broader extension than I expected, since we at present don't
ever do generic resolution based upon dynamic type.

It seems what you're proposing is a facility both for generic resolution
without invoking a specific or evaluating arguments, and determining
runtime dispatch without invoking the resulting procedure (but maybe
requiring evaluation of the pass_obj argument to get its type).

> The key is that the X is a different dummy argument to the 
> subroutine reduction.  The dummy itself might be declared class(*), so 
> the information has to come from the dynamic type of the actual 
> corresponding to X.   I don't see how this information is available if 
> all you have is an explicit interface for the dummy PROC.  The dummy 
> arguments in that interface don't have a connection to the dummy 
> arguments to reduction.

No, they have a connection to the dummy arguments of the actual argument
procedure.

> 
> Cheers,
> Bill
> 
> 
> 
> 
>