(j3.2006) question about generic resolution

[Craig Dedo]

Bill and Everyone Else:
	I believe that you are somewhat mistaken in your assumptions.  I would like to
clarify below.

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 10:57
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) question about generic resolution
> 
> Craig Dedo wrote:
> 
> > 	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.
> 
> I suspect my description was not as clear as you suggested.  In Fortran
> 2003, allocatable and pointer attributes were not considered
> sufficiently different to make a two dummy arguments distinguishable.

	I understood that when I wrote my original message.  IIRC, I understood that when
we were working on Fortran 2003.  I considered it to be a wart then but deliberately chose
not to pursue it because we had many much more important items on our agenda, like getting
OOP and Interoperability with C correct.

> The new feature in Fortran 2008 was to make an allocatable argument
> distinguished from a pointer argument. So I see your argument above as
> one to keep the new Fortran 2008 feature.

	That is correct.  I definitely want PL22.3 and WG5 to keep the feature.  I do not
want either of them to remove it, even "temporarily".  In these kinds of situations,
"temporarily" often turns out to be permanently.

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

	Your example below persuades me to raise my evaluation of Option 1 somewhat.  I
now consider it to be "marginally acceptable".  It may prove to be the most viable option,
either technically, politically, or both.  If so, FWIW, I would reluctantly agree to this
approach.
 
> I included option 1 partly for completeness, and partly because Aleks
> said we should not write this off as a possibility. It also results in a
> 'technical fix' to the draft as opposed to a 'change in the feature
> content', which might be more in keeping with the spirit of the rules.
> I believe there is some benefit to allowing a 'priority' scheme for
> generic resolution, even though it is a change from the basics of the
> current design.  In the discussion of TYPE(*), we had to decide on how
> to handle it in the context of generic resolution.  We opted for the
> simple solution [you have to depend on other arguments being
> distinguishable].  We did discuss a bigger change that would have made
> an interface like this legal:
> 
>    interface s
>       subroutine si (x)
>         integer :: x(:)
>       end subroutine si
> 
>      subroutine sr(x)
>         real :: x(:)
>      end subroutine sr
> 
>      subroutine st(x)
>         type(*) :: x(:)
>      end subroutine st
>   end interface s
> 
> The idea here is that si and sr would be optimized implementations for
> the specific argument type [which might be chosen 90+% of the time]
> whereas st is a wrapper to a C routine with a corresponding descriptor
> argument and the routine has a big switch statement on the type code,
> and hence is more general but has a lot of overhead, for the rare other
> cases.  The generic resolution rule we discussed was that an EXACT match
> (integer actual leads to call to si) always wins.  The st routine with
> the type(*) argument is chosen as the last resort - sort of like a 'case
> default' for generic interfaces.   Certainly such an 'exact match'
> requirement could be applied to an allocatable attribute as well, to
> prefer it over an alternative routine with the pointer dummy argument.
> 
> Perhaps an option for right now would be to go with option 2 (delete the
> current f08 feature), and reintroduce it in a later standard in the more
> general context that would also cover type(*)  [ and dimension(..)].
> The wording to get this right is not trivial, so attempting it today
> seems ill-advised.
> 
> Cheers,
> Bill