(j3.2006) question about generic resolution

[Aleksandar Donev]

On Wednesday 24 March 2010, Bill Long wrote:

> In an attempt to summarize ...
Thanks, this is better than flame wars, but I think the list is 
incomplete. As some said for the issue of broken description of 
intrinsics, it might be better to deal with issues like this through the 
interp process rather than try to fix them on the spot here.

But before the technical, I do feel I need to comment on the flame war 
bait:
> \begin{OpEdComment}
>     This situation points out the inherent weakness in the argument
> "We should add feature xxx because I can't think of a reason not
> to.". \end{OpEdComment}
This was not the reason we added any of these features. We went through 
a long selection process. They have intrinsic value, and we could not 
think of a conflict as a reason to reject them (this is not the same as 
the reason to accept them!).
Coarrays have/had conflicts with the whole rest of the standard. For 
example, they have a fundamental (to use Malcolm's phrase) conflict with 
OOP (type extension is essentially broken for coarray components). We 
found ways to work around it, in less than ideal or perfect ways, but we 
understood that compromises need to be made to make this work in the 
time we had.

In this spirit, your 
> 4) Delete both features. Advantages and disadvantages are as above.
is *unacceptable*, and not mandated by any kind of process or technical 
justification. Just because you and whoever else never liked something 
to begin with is not a reason, yet alone a good reason, for undoing hard 
work others have put in.

> 1) Leave both features in, but modify the generic resolution rules
> such that the ambiguity is resolved in favor of the Fortran 2003 rule
> that allocatable dummy corresponds to allocatable actual.
Or, as you commented later,
1a) Do 2 now and then later actually do the work to make generics 
preference-based (something Kurt promissed to do when I first joined J3 
but unfortunatelly he left before it got done).

> 2) Delete the allocatable .vs. pointer distinguishing of dummy
> arguments feature.

> 3) Delete the pointer,intent(in) dummy corresponds to non-pointer
> actual feature.

I add my own preference:

4) Modify the ruls so that one cannot write a generic like this. For 
example, do not allow "pointer, INTENT(IN)" (caps serve an emphasis 
purpose here) and "allocatable" to be used for disambiguation. The uses 
of pointer-vs-allocatable feature I can think of, such as memory 
management routines, would have INTENT(INOUT) pointer dummies, since 
they would actually do something with the pointer. Otherwise simple 
"temp pointer" on the caller side would do the trick.

and other options include, but are likely not limited to,

5) Make the auto-targetting feature (mentioned in #3) only work with 
non-generic calls.

Best,
Aleks
-- 
Aleksandar Donev, Ph.D.
Luis W. Alvarez Postdoctoral Fellow
Center for Computational Sciences and Engineering (https://ccse.lbl.gov)
Lawrence Berkeley National Laboratory (http://www.lbl.gov)
E-mail: adonev at lbl.gov
Phone: (510) 486-5782  Fax: (510) 486-6900
Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720
Web: http://cims.nyu.edu/~donev/