A Homework Question from the GNU Fortran crowd.

Bug report 17379 (http://gcc.gnu.org/PR17379) has the following analysis:

<QUOTE>
$ cat generic_bug.f90
module vector_i_module

implicit none

type vector_i
integer :: size = 0
end type vector_i

interface size
module procedure vector_size_i
end interface size

contains

function vector_size_i(d) result(r)
integer :: r
type(vector_i), intent(in) :: d
r = d%size
end function vector_size_i

subroutine vector_reverse_i(d)
type(vector_i), intent(inout) :: d
integer :: i,n
n = size(d)
end subroutine vector_reverse_i

end module vector_i_module
$ gfortran generic_bug.f90
In file generic_bug.f90:24

n = size(d)
1
Error: Symbol 'size' at (1) has no IMPLICIT type
</QUOTE>

I'm clearly outclassed here.  Is the type of the interface size
determined by the result type of its module procedure (and is gfortran
therefore wrong in issuing an error), or not ?

[ I have to add that this contest is prizeless ]

--
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

Toon Moene <toon@moene.indiv.nluug.nl> wrote:
>Bug report 17379 (http://gcc.gnu.org/PR17379) has the following analysis:
>
><QUOTE>
>$ cat generic_bug.f90
>module vector_i_module
>
>   implicit none
>
>   type vector_i
>      integer :: size = 0
>   end type vector_i
>
>   interface size
>      module procedure vector_size_i
>   end interface size
>
>contains
>
>   function vector_size_i(d) result(r)
>     integer :: r
>     type(vector_i), intent(in) :: d
>     r = d%size
>   end function vector_size_i
>
>   subroutine vector_reverse_i(d)
>     type(vector_i), intent(inout) :: d
>     integer :: i,n
>     n = size(d)
>   end subroutine vector_reverse_i
>
>end module vector_i_module
>$ gfortran generic_bug.f90
>  In file generic_bug.f90:24
>
>     n = size(d)
>            1
>Error: Symbol 'size' at (1) has no IMPLICIT type
></QUOTE>
>
>I'm clearly outclassed here.  Is the type of the interface size
>determined by the result type of its module procedure (and is gfortran
>therefore wrong in issuing an error), or not ?

I think result type is determined by the module procedure, just as if vector
_size_i
were called directly, so gfortran appears to be mistaken.

The code compiles with Compaq Visual Fortran 6.6c and Lahey/Fujitsu Fortran
95 5.70c without errors or warnings.



----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==--
--
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 News
groups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

Toon Moene wrote:

(snip)

>   function vector_size_i(d) result(r)
>     integer :: r
>     type(vector_i), intent(in) :: d
>     r = d%size
>   end function vector_size_i

>   subroutine vector_reverse_i(d)
>     type(vector_i), intent(inout) :: d
>     integer :: i,n
>     n = size(d)

(snip)

I find this confusing, but maybe it is obvious
to others.   Are the d%size and size(d) related?
That is, are the sizes the same size?

As a note, probably completely unrelated to Fortran,
but interesting for comparison purposes, PL/I allows
structures (derived types) to be referenced with partial
qualification as long as there is no ambiguity.
(Ambiguity must be at the same nesting level.)

In a routine containing d, then, d%size is fully qualified
but size would be partially qualified and unique in this case,
and have the same meaning as d%size.   A size function not
declared in the same block could not be referenced.

Parial qualification may or may not be a good idea.

-- glen

glen herrmannsfeldt wrote:
>
>
> Toon Moene wrote:
>
> (snip)
> 
>
> 
>
>
> (snip)
>
> I find this confusing, but maybe it is obvious
> to others.   Are the d%size and size(d) related?
> That is, are the sizes the same size?
>
> As a note, probably completely unrelated to Fortran,
> but interesting for comparison purposes, PL/I allows
> structures (derived types) to be referenced with partial
> qualification as long as there is no ambiguity.
> (Ambiguity must be at the same nesting level.)
>
> In a routine containing d, then, d%size is fully qualified
> but size would be partially qualified and unique in this case,
> and have the same meaning as d%size.   A size function not
> declared in the same block could not be referenced.
>
> Parial qualification may or may not be a good idea.
>
> -- glen
>

Glen, you snipped out a key piece of code here: the initial interface
block associating the generic name size() with the specific name
vector_size_i().

It appears that gfortran is not correctly recognizing the size(d)
reference as a generic invocation of the vector_size_i() function. Which
is clearly a compiler bug.

cheers,

Rich


--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

glen herrmannsfeldt wrote:
...
> As a note, probably completely unrelated to Fortran,
> but interesting for comparison purposes, PL/I allows
> structures (derived types) to be referenced with partial
> qualification as long as there is no ambiguity.
> (Ambiguity must be at the same nesting level.)
>
> In a routine containing d, then, d%size is fully qualified
> but size would be partially qualified and unique in this case,
> and have the same meaning as d%size.   A size function not
> declared in the same block could not be referenced.
>
> Parial qualification may or may not be a good idea.


The LWG Fortran proposal (1982) had the same suggestion.
So, it's not like the Fortran committee didn't investigate the
idea.  I don't like it since small changes to *apparently*
unrelated code can make unqualified references ambiguous.
Of course, the compiler can detect the problem, so it won't
cause serious error, but it's just another thing that makes
for maintenence problems.  (I like the ability to resolve
the ambiguity explicitly by allowing alias names - like the
ASSOCIATE construct, for example.  I'd have probably
made the syntax different, but the concept is useful.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare