generic INTERFACE and name clash

Oskar Enoksson

unread,

Sep 21, 2007, 3:20:21 AM9/21/07

to

Is it ok to declare a generic interface with a name identical to the
module procedure? What about if two different modules doing this are
used from the same program? I.e. in the example below, will the
interfaces remedy the name clash between the two module procedures below?

MODULE M1
INTERFACE FOO
MODULE PROCEDURE FOO
END INTERFACE
CONTAINS
SUBROUTINE FOO(I)
INTEGER, INTENT(IN) :: I
WRITE(*,*) 'INTEGER'
END SUBROUTINE FOO
END MODULE M1

MODULE M2
INTERFACE FOO
MODULE PROCEDURE FOO
END INTERFACE
CONTAINS
SUBROUTINE FOO(R)
REAL, INTENT(IN) :: R
WRITE(*,*) 'REAL'
END SUBROUTINE FOO
END MODULE M2

PROGRAM P
USE M1
USE M2
CALL FOO(10)
CALL FOO(10.)
END PROGRAM P

(By experiment it works with gfortran, ifort, pathf95 and lf95, but not
with an old version 6.0 of pgf95.)

-bash-2.05b$ pgf95 -o tst tst.f90
PGF90-S-0155-foo is use-associated from modules m2 and m1, and cannot be
accessed (tst1.f90: 35)
PGF90-S-0155-foo is use-associated from modules m2 and m1, and cannot be
accessed (tst1.f90: 36)

Message has been deleted

James Van Buskirk

unread,

Sep 21, 2007, 12:21:36 PM9/21/07

to

"Oskar Enoksson" <enok_ta...@lysator.liu.se> wrote in message
news:fcvj5i$e1j$1...@news.lysator.liu.se...

> -bash-2.05b$ pgf95 -o tst tst.f90
> PGF90-S-0155-foo is use-associated from modules m2 and m1, and cannot be
> accessed (tst1.f90: 35)
> PGF90-S-0155-foo is use-associated from modules m2 and m1, and cannot be
> accessed (tst1.f90: 36)

Yep, pgf95 has got it right. If program P had a line like:

call bar(foo)

the compiler would not know which specific version of foo to
send. Only one copy of the same specific name can be visible
in a scoping unit; you would have the same problem if the
specific subroutine names were both 'joe' and the generic
name were 'foo'.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

paul.rich...@gmail.com

unread,

Sep 22, 2007, 1:02:11 PM9/22/07

to

James,

>
> Yep, pgf95 has got it right. If program P had a line like:
>
> call bar(foo)
>
> the compiler would not know which specific version of foo to
> send. Only one copy of the same specific name can be visible
> in a scoping unit; you would have the same problem if the
> specific subroutine names were both 'joe' and the generic
> name were 'foo'.

That's spot on - Thank you. gfortran survives the original example
because it distinguishes the interfaces. However, as you say, the
ambiguity comes with specific references.

Could you raise a bug report, please, Oskar? I'll turn to it, just as
soon as I have sorted out a couple of other niggles.

Cheers

Paul Thomas

Herman D. Knoble

unread,

Sep 24, 2007, 7:34:06 AM9/24/07

to

Craig:

Explicitly, what would be a better (fortunate) way to write this code?

Thanks.
skip knble

On Fri, 21 Sep 2007 07:59:55 -0500, "Craig Dedo" <cd...@wi.rr.com> wrote:

Oskar Enoksson

unread,

Sep 24, 2007, 8:46:15 AM9/24/07

to

Someone else has reported it. But is the concensus that my program
should be rejected or not? The bugreporter "burnus" seems to think it is
legal unless FOO is itself used as an actual argument.

/Oskar

Craig Dedo

unread,

Sep 24, 2007, 9:42:32 AM9/24/07

to

"Herman D. Knoble" <SkipKno...@SPAMpsu.DOT.edu> wrote in message
news:828ff3dd1dqf0grh8...@4ax.com...

> Craig:
>
> Explicitly, what would be a better (fortunate) way to write this code?
>
> Thanks.
> skip knble

My general approach is to implement recommended best practices of
software construction and modular decomposition, given the nature of the
problem and any constraints imposed by the insitutional environment. One of
the best books I have read on software construction practices is Steve
McConnell's Code Complete: A Practical Handbook of Software Construction,
1st and 2nd editions. Although the author has a very negative view of
Fortran and the 2nd edition is strongly oriented toward the Microsoft Visual
Studio languages, the book is chock full of sound advice about all aspects
of software construction. There is an entire chapter in both editions
devoted to choosing good names.

That said, here is what I would recommend. I would define the generic
interface name and all of the specifics in one module. If a subroutine,
generic name would be a strong verb followed by a direct object. If a
function, the generic name would be descriptive of the return result.

If there are a lot of specifics in the generic, then it would make sense
to decompose the module according to the principles of modular
decomposition. I usually follow the rule of thumb used in project
management that each summary task should contain 2 - 20 immediate
subordinate tasks. Similarly, each module should contain 2 - 20 specific
procedures.

Each of the specific names would be the generic name followed by a sufix
that describes the data type of the arguments. I do not have a firm
convention for data type suffixes.
* I tend to use In for integers, where n is the number of 8-bit bytes. This
follows the convention used by almost all Fortran compilers for assigning
KIND numbers to integer kinds.
* For Reals, I usually use either a suffix of Rn, again where the n is the
KIND number or else suffixes of RSP for Single Precision, RDP for Double
Precision, and RXP for Extended Precision.
* Complex suffixes would use either Cn or else CSP, CDP, and CXP.
* I have not had the pleasure of working with multiple kinds of Character,
since no Fortran compiler has yet implemented ISO 10646 kinds. However,
following the current pattern, it would make sense to use S1 for ASCII, S2
for ISO 10646 UCS-2, and S4 for ISO 10646 UCS-4. In my experience, UTF-8
and UTF-16 are used mostly for file encoding, not for internal variables.
However, following this convention, SU8 and SU16 could be used for UTF-8 and
UTF-16 respectively.
* I don't have any convention for Logical arguments. Usually, there are
only zero or one Logical arguments per procedure reference.
* Obviously, this convention breaks down for arguments that are of derived
type or procedure interfaces that contain arguments of two or more intrinsic
types. In these cases, you may need to implement suffixes using some
sensible numbering system, rather than the mnemonic suffixes I have used
above.

Now that I have described the general convention, here is how I would
rewrite the example. Unfortunately, the name FOO does not give me the
foggiest ideas of what the subroutine does, so I cannot think of a more
descriptive subroutine name.

Module Foo_Generic_M

! Define generic interface for Subroutine Foo() for 2, 4, and 8 byte
integers and single precision and double precision reals.

Interface
Module Procedure Foo_I2
Module Procedure Foo_I4
Module Procedure Foo_I8
Module Procedure Foo_RSP
Module Procedure Foo_RDP
End Interface

Contains

! Define specific subroutines for generic subroutine Foo().
Subroutine Foo_I2 (A)
Integer(Kind=2), Intent(IN) :: A
Write (*,*) "Integer Kind=2"
End Subroutine Foo_I2 (A)

Subroutine Foo_I4 (A)
Integer(Kind=4), Intent(IN) :: A
Write (*,*) "Integer Kind=4"
End Subroutine Foo_I4 (A)

Subroutine Foo_I8 (A)
Integer(Kind=8), Intent(IN) :: A
Write (*,*) "Integer Kind=8"
End Subroutine Foo_I8 (A)

Subroutine Foo_RSP (A)
Use Kind_Definitions_M ! Defines named constants for KIND type
parameters.
Real (Kind=SP), Intent(IN) :: A
Write (*,*) "Real Kind=SP"
End Subroutine Foo_RSP (A)

Subroutine Foo_RDP (A)
Use Kind_Definitions_M ! Defines named constants for KIND type
parameters.
Real (Kind=DP), Intent(IN) :: A
Write (*,*) "Real Kind=DP"
End Subroutine Foo_RDP (A)

End Module Foo_Generic_M
Use Kind_Definitions_M ! Defines named constants for KIND type
parameters.
Program Demo_Foo_Generic
Use Foo_Generic_M
Call Foo (10_2)
Call Foo (10_4)
Call Foo (10_8)
Call Foo (10.0_SP)
Call Foo (10.0_DP)
End Program Demo_Foo_Generic

--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>

Herman D. Knoble

unread,

Sep 24, 2007, 12:21:51 PM9/24/07

to

Craig: Thanks for sharing your wisdom here. I'd like to quote your prose and
example code for my students. It would be even better documentation
than it already is if the code were actually compilable/runable.

Again, many thanks.
skip

On Mon, 24 Sep 2007 08:42:32 -0500, "Craig Dedo" <cd...@wi.rr.com> wrote:

James Van Buskirk

unread,

Sep 24, 2007, 3:08:58 PM9/24/07

to

"Oskar Enoksson" <enok_ta...@lysator.liu.se> wrote in message

news:fd83cb$ik8$1...@news.lysator.liu.se...

> Someone else has reported it. But is the concensus that my program should
> be rejected or not? The bugreporter "burnus" seems to think it is legal
> unless FOO is itself used as an actual argument.

There doesn't seem to be a consensus as yet. I consider ISO/IEC
1539-1:1997(E)
section 14.2.2 Local Entities:

"Within a scoping unit, entities in the following classes:
(1) ... module procedures ...
are local entities of that scoping unit."

"Within a scoping unit, a name that identifies a local entity of one

class shall not be used to identify another local entity of the same
class, except in the case of generic names (12.3.2.1)."

This says to me that the code as given was nonconforming because the
name FOO was used to identify the module procedure SUBROUTINE FOO
from MODULE M1 as well as the module procedure SUBROUTINE FOO from
MODULE M2. The case of generic names says to me that any number of
generic identifiers may have the same name as one module procedure
provided any possible generic procedure reference is unambiguous
(section 14.1.2.3). In the following example, there is no problem
about module procedures 'joe' having the same generic identifier
somehow, yet gfortran doesn't seem to mind it:

C:\gfortran\clf\foo_conflict>type joe_conflict.f90
MODULE M1
INTERFACE FOO
MODULE PROCEDURE joe
END INTERFACE
CONTAINS
SUBROUTINE joe(I)

INTEGER, INTENT(IN) :: I
WRITE(*,*) 'INTEGER'

END SUBROUTINE joe
END MODULE M1

MODULE M2
INTERFACE FOO
MODULE PROCEDURE joe
END INTERFACE
CONTAINS
SUBROUTINE joe(R)

REAL, INTENT(IN) :: R
WRITE(*,*) 'REAL'

END SUBROUTINE joe
END MODULE M2

PROGRAM P
USE M1
USE M2
CALL FOO(10)
CALL FOO(10.)
END PROGRAM P

C:\gfortran\clf\foo_conflict>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
jo
e_conflict.f90 -ojoe_conflict

C:\gfortran\clf\foo_conflict>joe_conflict
INTEGER
REAL

In PROGRAM P, there are two class 1 entities with the name 'joe',
but gfortran doesn't seem to mind. 'joe' is not a generic name.

James Van Buskirk

unread,

Sep 24, 2007, 3:17:06 PM9/24/07

to

"Craig Dedo" <cd...@wi.rr.com> wrote in message
news:46f7beca$0$28849$4c36...@roadrunner.com...

> That said, here is what I would recommend. I would define the generic
> interface name and all of the specifics in one module.

That is pretty much at orthogonal trajectories to what I would do.
Instead, I generally define all specific procedures of one type
and kind in one module and then define the generic name in a module
that uses the above modules. This permits templating so that I
can get double- and quadruple-precision complex BLAS procedures from
a single complex code base in
http://home.comcast.net/~kmbtib/Fortran_stuff/GENERIC_BLAS.ZIP .

Also see http://home.comcast.net/~kmbtib/codelets.ZIP , which is an
older use of templates in Fortran.

Richard Maine

unread,

Sep 24, 2007, 4:30:28 PM9/24/07

to

James Van Buskirk <not_...@comcast.net> wrote:

> "Oskar Enoksson" <enok_ta...@lysator.liu.se> wrote in message
> news:fd83cb$ik8$1...@news.lysator.liu.se...
>
> > Someone else has reported it. But is the concensus that my program should
> > be rejected or not? The bugreporter "burnus" seems to think it is legal
> > unless FOO is itself used as an actual argument.
>
> There doesn't seem to be a consensus as yet. I consider ISO/IEC
> 1539-1:1997(E)
> section 14.2.2 Local Entities:
>
> "Within a scoping unit, entities in the following classes:
> (1) ... module procedures ...
> are local entities of that scoping unit."
>
> "Within a scoping unit, a name that identifies a local entity of one
> class shall not be used to identify another local entity of the same
> class, except in the case of generic names (12.3.2.1)."
>
> This says to me that the code as given was nonconforming because the
> name FOO was used to identify the module procedure SUBROUTINE FOO
> from MODULE M1 as well as the module procedure SUBROUTINE FOO from
> MODULE M2.

Well, it is subtle. First, note that I'd never recommend actually doing
anything like this, but that isn't the question. The question is about
whether the standard allows it, independent of how bad an idea it might
be.

The tricky part here is the question of whether the name identifies a
local entity in the scoping unit in question. If you actually do
anything with the name, then it does identify a local entity, and thus
the code would be illegal. By "do anything" I mean the name appearing at
all, either as a reference or in any other context. (Yes, there are
several contexts other than a reference that a procedure name can appear
in). But if the name never appears, one could argue that the name
doesn't identify anything in the scoping unit. Yes, that's a subtle
argument. It is one I might not even give credence to... except that
there is a quote elsewhere in the standard that makes it pretty
exlpicit. From f2003 (that's closer at hand than f95 right now), pg 252,
lines 25:26

"Two or more accessible entities, other than generic interfaces or
defined operators, may have the same identifier only if the identifier
is not used to refer to an entity in the scoping unit)."

That's a tricky bit, and one I have forgotten about before. I almost
forgot that it applied here and gave the wrong answer again, but I
caught myself in time. Anyway, I think I got it right now.

I'd have to say, though, that fixing a compiler that failed to allow his
would be awfully low on my priority list. I'm sure any compiler out
there has more important things than this to fix. :-( I'd say that it at
least merits a warning along the line of "the standard allows this, but
are you sure that's really what you meant?"

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Tobias Burnus

unread,

Sep 24, 2007, 4:47:21 PM9/24/07

to

On 24 Sep., 21:08, "James Van Buskirk" <not_va...@comcast.net> wrote:

> "Oskar Enoksson" <enok_tabort...@lysator.liu.se> wrote:
> > Someone else has reported it.

I did as it was not yet reported and I feared that it might get
forgotten.

> > But is the concensus that my program should
> > be rejected or not? The bugreporter "burnus" seems to think it is legal
> > unless FOO is itself used as an actual argument.

No, I thought that it was probably invalid, however, I was not
completely sure and wanted to recheck the Fortran standard* -
especially after even NAG f95 and Lahey accepted it without any error.
The point I made was only: As actual argument it is ambiguous (unless
there is an explicit interface), otherwise it is not ambiguous. The
ambiguity has nothing to do with whether it is valid according to the
Fortran standard (except that a good standard should try hard to
disallow things which are ambiguous). And after re-reading parts of
the standard, I am convinced that it is invalid, unless someone points
out something in the standard which I overlooked or misinterpreted.

(* I have serious trouble to find the right spot in the standard and
to read it as written and not as it can be interpreted thinking
laterally.)

> In the following example, there is no problem
> about module procedures 'joe' having the same generic identifier
> somehow, yet gfortran doesn't seem to mind it:

I don't see the contradiction (which the "yet" implies) between "there
is no problem" and "gfortran does not seem to mind it". The following
program is valid as JOE is never referred and thus this restriction
does not apply:

"Two or more accessible entities, other than generic interfaces or
defined operators, may have the same identifier only if the identifier

is not used to refer to an entity in the scoping unit." (Fortran 2003,
"11.2.1 The USE statement and use association")

And as the use-associated "JOE" is not used in the main program, there
is no problem.

(By the way, using "external bar; call bar(foo)" fails here as there
is no specific function FOO and a generic function cannot be used as
actual argument.)

Coming back to the initial program, which is the same as above except
with the word "JOE" replaced by "FOO".

USE makes both the specific FOO and the generic FOO identifier
accessible and the following applies:

"Two or more accessible entities, other than generic interfaces or
defined operators, may have the same identifier only if the identifier

is not used to refer to an entity in the scoping unit." (Fortran 2003,
"11.2.1 The USE statement and use association")

If one now uses the specific procedure FOO then the program is
invalid. Using the generic interface FOO is in principle ok, except
that both the specific and the generic subroutines have the same name.

One could now argue that in "CALL FOO(10)" only the generic interface
and not the specific procedure FOO is referred and that thus the
program is valid. However, one can also say FOO and FOO are the same
identifier and thus "CALL FOO(10)" is invalid. I am in favour of the
latter, which is also in line with the error given by Pathscale and
g95, and which implies that the original program is invalid (as
already written by James Van Buskirk and acknowledged by Paul Thomas).

Tobias

James Van Buskirk

unread,

Sep 24, 2007, 5:18:37 PM9/24/07

to

"Richard Maine" <nos...@see.signature> wrote in message
news:1i4y4m4.4o9m1dv5oscqN%nos...@see.signature...

> "Two or more accessible entities, other than generic interfaces or
> defined operators, may have the same identifier only if the identifier
> is not used to refer to an entity in the scoping unit)."

> That's a tricky bit, and one I have forgotten about before. I almost
> forgot that it applied here and gave the wrong answer again, but I
> caught myself in time. Anyway, I think I got it right now.

OK, this makes clear what the standard thinks about modules: they
contain mostly garbage! If they contained mostly good stuff, there
would be a requirement that a module USEr would have to straighten out
any overlapping stuff via ONLY clauses or renaming. Since modules
contain mostly garbage, the USEr is supposed to fix up any landmines
by recursively searching through any USEd modules as each conflict
arises.

So let's make up a conforming and a nonconforming example, shall we?

C:\gfortran\clf\foo_conflict>type landmine1.f90
! File: landmine1.f90
! Public domain 2007 James Van Buskirk

module M1
real x
end module M1

module M2
contains
subroutine y
end subroutine y
end module M2

module M3
use M2, x => y
end module M3

module M4
use M1
use M3
end module M4

module M5
use M4
end module M5

module M6
use M5
end module M6

program test
use M6

write(*,*) 'Hello, world!'
end program test

! End of file: landmine1.f90

C:\gfortran\clf\foo_conflict>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran

la
ndmine1.f90 -olandmine1

C:\gfortran\clf\foo_conflict>landmine1
Hello, world!

C:\gfortran\clf\foo_conflict>type landmine2.f90
! File: landmine2.f90
! Public domain 2007 James Van Buskirk

module M1
real x
end module M1

module M2
contains
subroutine y
end subroutine y
end module M2

module M3
use M2, x => y
end module M3

module M4
use M1
use M3
end module M4

module M5
use M4
end module M5

module M6
use M5
end module M6

program test
use M6
interface
function x(z)
end function x
end interface

write(*,*) 'Hello, world!'
end program test

function x(z)
x = z
end function x

! End of file: landmine2.f90

C:\gfortran\clf\foo_conflict>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran

la
ndmine2.f90 -olandmine2
landmine2.f90:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

As we can see, gfortran comnpiles landmine1.f90 correctly, and
also ICEs as required by the standard when confronted by the
nonconforming example landmine2.f90.

BTW, your quote of the standard at the top of this post shows
unambiguously that the original code of the thread is nonconforming:
two or more accessible entities, other than generic identifiers
indeed have the same identifier (subroutine foo from module M1
and subroutine foo from module M2, both in program P) and the
identifier is used to refer to an entity in the scoping unit
(generic name foo).

James Van Buskirk

unread,

Sep 24, 2007, 5:28:56 PM9/24/07

to

"Tobias Burnus" <bur...@net-b.de> wrote in message
news:1190666841.1...@50g2000hsm.googlegroups.com...

> "Two or more accessible entities, other than generic interfaces or
> defined operators, may have the same identifier only if the identifier
> is not used to refer to an entity in the scoping unit." (Fortran 2003,
> "11.2.1 The USE statement and use association")

I had not been aware of this until you & Richard pointed it out.
I now agree that my version you quoted (with 'joe') was indeed
conforming and that the original version (with 'foo') was
nonconforming. I posted an example a couple of minutes ago
where 'referring to an entity' happened via an interface block.
Other possibilities I haven't checked are in a use, only clause
or in a use with renaming (on either end).

gary.l...@lmco.com

unread,

Sep 24, 2007, 5:51:21 PM9/24/07

to

On Sep 24, 8:42 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
> "Herman D. Knoble" <SkipKnobleL...@SPAMpsu.DOT.edu> wrote in messagenews:828ff3dd1dqf0grh8...@4ax.com...

>
> > Craig:
>
> > Explicitly, what would be a better (fortunate) way to write this code?
>
> > Thanks.
> > skip knble
>
> My general approach is to implement recommended best practices of
> software construction and modular decomposition, given the nature of the
> problem and any constraints imposed by the insitutional environment. One of
> the best books I have read on software construction practices is Steve
> McConnell's Code Complete: A Practical Handbook of Software Construction,
> 1st and 2nd editions. Although the author has a very negative view of
> Fortran and the 2nd edition is strongly oriented toward the Microsoft Visual
> Studio languages, the book is chock full of sound advice about all aspects
> of software construction. There is an entire chapter in both editions
> devoted to choosing good names.

<snip>

Was curious as to how familiar McConnell is with F95 or F2k3 or
whether the negativity is directed at prior standards?

Paul van Delst

unread,

Sep 24, 2007, 7:42:28 PM9/24/07

to

Dunno about 2nd edition, but my 1993 copy tells me:

"As of this writing (late 1992) the Fortran standard is so controversial that most
language vendors have not fully implemented it. The discussions in this book confine
themselves to Fortran 77."

My impression about references to Fortran (as in 77) in that book wasn't that the language
itself was "bad", just "old"; i.e. it allowed so many things that violated the general
consensus (of commercial software designers/writers/etc) about what constituted well
constructed software in 1993. I wouldn't characterise that as a "negative view"... just,
uh, lacking in context, maybe? (Waving hands wildly in the air here :o)

cheers,

paulv

Oskar Enoksson

unread,

Sep 25, 2007, 3:11:51 AM9/25/07

to

Tobias Burnus wrote:
> On 24 Sep., 21:08, "James Van Buskirk" <not_va...@comcast.net> wrote:
>> "Oskar Enoksson" <enok_tabort...@lysator.liu.se> wrote:
>>> Someone else has reported it.
> I did as it was not yet reported and I feared that it might get
> forgotten.

Yes, thanks. And thanks very much for the very clear explanation below
of the dilemma. Looks like the standard could need some clarification on
this point. Until that is settled I'll find another way in my program.

/Oskar

Craig Powers

unread,

Sep 26, 2007, 2:30:56 PM9/26/07

to

If I may make a minor quibble...

James Van Buskirk wrote:
> As we can see, gfortran comnpiles landmine1.f90 correctly, and
> also ICEs as required by the standard when confronted by the
> nonconforming example landmine2.f90.

...it's never correct for a compiler to ICE, even in the event of
nonconforming code (although ICE on invalid will presumably be a
lower-priority bug than ICE on valid).

(If you were being sarcastic, it was disguised a little too well.)

James Van Buskirk

unread,

Sep 26, 2007, 2:44:59 PM9/26/07

to

"Craig Powers" <eni...@hal-pc.org> wrote in message
news:46faa560$0$63183$a726...@news.hal-pc.org...

> James Van Buskirk wrote:

I don't care for laugh tracks and don't watch sitcoms anyhow, and in
a similar vein think emoticons are rather overused. Can't you see
the flashing LAUGHTER and APPLAUSE signs out there in the audience?
Right there above the monitor?