(j3.2006) question about generic resolution

[Craig Dedo]

Everyone:
	Bill, thank you very much for your clear, detailed summary of the
debate on this issue.  It clearly explains and summarizes the options and
their advantages and disadvantages in an even-handed manner.  

	FWIW, I no longer have a vote, but here are my opinions on each
option.  This is purely from the perspective of an application developer who
is using the language to build an application.

	I strongly dislike option 2.  It conflates the concepts of pointers
and allocatables.  Conflating two different concepts, even if it's only in
one narrow context, is almost always very bad language design.  Such
practices are a notorious source of conceptual and programming errors, even
for experienced developers.  In the minds of many (most?) application
developers, pointers and allocatables are very different concepts.  This is
true even though both kinds of data objects can be the (grammatical) object
of an Allocate statement and implementation methods for pointers and
allocatables may be very similar.  Two specific procedures in a generic
procedure should be considered different if in one argument N is an
allocatable and in the other argument N is a TKR-compatible pointer.

	Option 4 is slightly less objectionable.  It gets rid of the
problem, but deletes functionality that some application developers have
found to be quite useful in their situations.  This one should be used only
as a method of last resort.

	Option 1 is marginally unacceptable, for the stated reasons.  It
introduces additional complexity into the issue of generic resolution, in a
situation where the additional complexity is perhaps unnecessary.

	Option 3 appears to be the best of the four.  It reduces the
functionality of the new features by the least scope and with an actual
slight improvement (i.e., reduction) in complexity of the generic resolution
rules.  I strongly support option 3 in preference to any of the others.

	Na?ve question:  Why was it ever considered useful or desirable to
have a non-pointer actual argument correspond to a pointer dummy argument?
This practice appears to contradict the Fortran tradition of strong data
typing.

	Of course, any constructive comments or criticisms on any of this
are welcome.

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                  Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo

-----Original Message-----
From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf
Of Bill Long
Sent: Wednesday, March 24, 2010 08:21
To: fortran standards email list for J3
Subject: Re: (j3.2006) question about generic resolution


In an attempt to summarize ...

The ISSUE:  The new f08 feature of distinguishing dummy arguments in 
generic resolution based on ALLOCATABLE vs. POINTER attribute, and the 
new f08 feature of allowing a non-pointer actual argument (in 
particular, an allocatable one) to correspond to a pointer,intent(in) 
dummy argument, are fundamentally incompatible with each other as 
currently worded in N814.

Four possible resolutions:

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.

   Advantage:  Avoids deleting either feature.

   Disadvantage:  Goes against the long standing feature of generics 
that the set of specific interfaces in a generic are always 
distinguishable without any 'priority' rules.  Also, getting all the 
edits right is more work (higher risk) than the other options.

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

   Advantage: Solves the problem by simple edits to N1814.

   Disadvantage: This feature has been publicized in two places other 
than J3 documents: John's N1735 paper describing the new Fortran 2008 
features has a section on this, as well as (actually, because of N1735) 
Ian's published Fortran Forum tally of compiler conformance has a 
separate line item for this feature.  [Checking our compiler for changes 
to Ian's table was, in fact, what lead me down this path in the first 
place.]

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

   Advantage:  Solves the problem with only slightly more editing to 
N1814.  Also, the usefulness of this capability seems marginal, in that 
the dummy argument could be declared assumed-shape instead and 
accomplish most of the desired capability.  I speculate that users will 
not be aware of the performance hit from using this feature in some 
situations.

   Disadvantage:  In other places we have expanded the role of pointers, 
and this feature fits into that context.  There could be uses I don't 
see at the moment.

4) Delete both features. Advantages and disadvantages are as above.


Independent of what we decide to do, we need to decide when to do it: 
Now as an edit to N1814 [enough people have not voted yet that a ballot 
groundswell would be possible], or as an interp later.  If we decide on 
an interp,  I would still like to have the decision now since it affects 
currently ongoing implementation work.

\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}

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


_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3