(j3.2006) 17-152 and CO_REDUCE

[Van Snyder]

On Thu, 2017-05-18 at 09:30:30 MDT, Bill Long wrote:
> This is another example of gratuitous generality that serves no purpose.
> We have made that mistake enough times in the past that we should know
> better than to fall for it again.
> 
> In this particular case, there is a very good reason why these changes
> cannot work.  The OPERATION function is called from within the CO_REDUCE
> library code. Which is almost certainly going to be written in C or C++.
> Independent of the library implementation language, there is no chance
> that an interface for the function would be visible at the call site.
> Thus, the interface has to be fixed in the standard.  So, optional
> arguments are unacceptable.  A library routine would have no concept of
> how to call the function with a Fortran polymorphic argument, so that is
> also out. 

This wouldn't be a problem if CO_REDUCE were a coroutine.  There's
nothing in the standard that prevents a processor from implementing it
as a coroutine.

> Cheers,
> Bill
> 
> > On May 17, 2017, at 9:06 PM, Van Snyder <Van.Snyder at jpl.nasa.gov>
> wrote:
> > 
> > Imposing "exactly two arguments" on the OPERATION argument to
> CO_REDUCE
> > requires one to write a wrapper to use a function that has more than
> two
> > arguments, with those after the first two being optional.
> > 
> > I would prefer "OPERATION shall be a pure function with at least two
> > arguments; the result and each of the first two arguments shall be
> > scalar, nonallocatable, nonpointer, nonpolymorphic data objects with
> the
> > same type and type parameters as A.  The first two arguments shall not
> > be optional and any additional arguments shall be optional."
> > 
> > I also don't understand why the first two arguments can't be optional.
> > 
> > Are polymorphic dummy arguments really a problem?  If not, remove the
> > prohibition against polymorphic, and replace "type" with "declared
> > type".
> > 
> > If the processor is expected to enforce the requirements on OPERATION,
> > it should be required to have explicit interface.
> 
>