[J3] [EXTERNAL] Elemental type-bound functions not useful

[Van Snyder]

On Mon, 2021-03-29 at 12:51 +0000, Clune, Thomas L. (GSFC-6101) wrote:
> Is it absolutely necessary for a passed-object dummy argument to be
> polymorphic? An alternative is to require that one that does not have
> a polymorphic passed-object dummy argument is overridden in
> extensions.
>  
> This would not help you.  If your return type is polymorphic, then it
> still cannot be elemental.   And if the goal is to have a result that
> is a  concrete type that varies with each subclass, then just add a
> specific such method to each
>  subclass.      You just cannot overload the interfaces because that
> leads to ambiguity.

Polymorphic arrays  are allowed, but not arrays of polymorphic objects.
The dynamic type must be homogeneous. This is not incompatible with the
result variable of an elemental function being polymorphic, because the
dummy arguments necessarily have homogeneous dynamic type.

An allocatable result from an elemental function would not work,
because the result of an elemental reference would not be an array;
rather a collection of the correct number of objects, in random places.
A CLASSOF declaration for the result could be made to work.

An alternative is to provide such functions for each rank. It's not
clear that the rank-agnostic facilities will make this significantly
easier to do than just writing them out manually.

An alternative is not to require type-bound procedures to have a
polymorphic passed-object dummy argument. If this were done, one would
not have the nasty surprise of invoking a function, for example by way
of an operator, and getting a result of the base type, not the argument
type. A consequence is that it would be necessary to override such
procedures in every extension. This should be a constraint, so that the
processor is required to diagnose failure to do so. As things stand
now, it is "necessary" to overload elemental type-bound functions in
each extension, if this nasty surprise is to be avoided, but the
processor provides no warning if this was not done. This would also
address the problem that, in a type-bound operation, 
say OPERATOR(+), the operands are not required to be of the same
dynamic type. The function that implements the operation could issue an
error, but a run-time error is much less helpful than a compile-time
error.
This problem arose in work I was doing using extended-precision
arithmetic. In at least three earlier projects, undertaken before OO
existed in Fortran, this problem could have arisen: Quaternions,
multicomplex numbers, and "automatic" differentiation using W-
arithmetic. The codes in all these cases used defined operations, which
were not, of course, type bound, and did not, of course, have
polymorphic arguments. In a "modern" setting, programs that use type-
bound operations would be more fragile.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210329/7f478fbf/attachment-0001.htm>