(j3.2006) question about generic resolution

[Bill Long]

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


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

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



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