(j3.2006) reduction routine

[Bill Long]

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.   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.

Cheers,
Bill





-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101