Prev: MOLD and SOURCE in an allocate statement.
Next: Identify this function?
From: ralf.schaa on 13 Jun 2010 19:03
I have a module with a type defined and a CONTAINEd subroutine with a
function in its argument list, so an INTERFACE is required, as below.
The ifort compiler complains with "This derived type name has not been
declared." The solution would be to put the derived type in a
different module and USE it, but why doesn't the interface "see" the
derived type definition at the current module level? I'd really like
to have the derived type together with the subroutine in one module -
is it possible in some way?

Cheers
-Ralf

module test

implicit none
public

type Check
integer :: i
end type Check

contains

subroutine testCheck( func, i, j )
! "func" is a function defined in a different module
interface
function func( thisCheck, arg )
type( Check ) :: thisCheck
integer :: arg, func
end function func
end interface

integer, intent(in) :: i,j

! Do things
end subroutine testCheck

end module test
From: Richard Maine on 13 Jun 2010 19:31
ralf.schaa <ralf.schaa(a)gmail.com> wrote:

> I have a module with a type defined and a CONTAINEd subroutine with a
> function in its argument list, so an INTERFACE is required, as below.
> The ifort compiler complains with "This derived type name has not been
> declared." The solution would be to put the derived type in a
> different module and USE it, but why doesn't the interface "see" the
> derived type definition at the current module level? I'd really like
> to have the derived type together with the subroutine in one module -
> is it possible in some way?

Not in f95. This is quite a common complaint. It is related to a
decision made at the very first J3 meeting I ever attended (not yet as a
member) back in 1990. The original f90 standard as published said that
things were inherited into interface bodies. (My memory has gone hazy as
to whether the things in question were entity identifiers or just
implicit mappings, there being slightly different details involved, but
I think it was the larger question of identifiers, which is what you are
seeing).

Several people on J3 - apparently a majority - concluded that was a
mistake. An interpretation was passed that reversed what the original
publication of f90 said on the matter. I recall considerable controversy
as to whether it as allowed to make such a change via the interp
process, since it was not actually an error in the standard in the sense
of being internally inconsistent, impractical to implement, or anything
of the sort. It was just that some people had a retroactive change of
mind. Alternatively, maybe hadn't actually read the relevant part of the
standard; it was in such black and white that one couldn't very well
have read it and failed to understand. Anyway, the original published
version of f90 was revised by the interp.

I am of the opinion that was a mistake, partly for procedural reasons (I
think one should use the interp process only for errors and ambiguities
rather than to revisit decisions. Some have argued that "wrong"
decisions count as errors. I don't buy it. Sounds just like a change of
mind to me.) But I also think it was a mistake because it caused the
kind of problem you are seeing. *LOTS* of people have run into that kind
of problem.

Unfortunately, by the time people figured out that this rule caused such
problems, it was too late to change the f90 standard back to its
original published rule. By then, there were numerous compilers and more
programs that would have been broken by changing the rule back.

F2003 adds the IMPORT statement as a hack around the rule. In my view,
it is an inconsistent hack. The *ONLY* functionality of the IMPORT
statement is to undo the damage of that rule in a way that doesn't break
existing code that has grown to depend on the rule. But whatever the
merits or lack thereof, that's the situation. Look for the f2003 IMPORT
statement in your compiler. If it is supported, that's what it does.

P.S. Unrelated nit. I strongly discourage use of the term "CONTAINED" as
a description of a procedure. The standard has no such term and it is
ambiguous. There are multiple different categories of procedures that
might be said to be "contained", but they can be quite different. For
example, when I started reading your post, which talked about a derived
type and a contained procedure, I was not at first sure whether you were
talking about a module procedure or a type-bound procedure (which has
its binding after a CONTAINS statement). The correct term for what you
are talking about is a "module procedure."

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 13 Jun 2010 19:38
Richard Maine <nospam(a)see.signature> wrote:
> ralf.schaa <ralf.schaa(a)gmail.com> wrote:

>> I have a module with a type defined and a CONTAINEd subroutine with a
>> function in its argument list, so an INTERFACE is required, as below.
>> The ifort compiler complains with "This derived type name has not been
>> declared." The solution would be to put the derived type in a
>> different module and USE it, but why doesn't the interface "see" the
>> derived type definition at the current module level? I'd really like
>> to have the derived type together with the subroutine in one module -
>> is it possible in some way?

> Not in f95. This is quite a common complaint. It is related to a
> decision made at the very first J3 meeting I ever attended (not yet as a
> member) back in 1990. The original f90 standard as published said that
> things were inherited into interface bodies. (My memory has gone hazy as
> to whether the things in question were entity identifiers or just
> implicit mappings, there being slightly different details involved, but
> I think it was the larger question of identifiers, which is what you are
> seeing).

But wouldn't it still require some way to declare the type
inside func? That would be easiest to do with a module.

Otherwise, it doesn't really help much.

-- glen
From: ralf.schaa on 13 Jun 2010 20:27
Thanks for all the information Richard,

the IMPORT statement worked in my test-module.

Cheers
-Ralf
From: Richard Maine on 13 Jun 2010 21:02
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:
> > ralf.schaa <ralf.schaa(a)gmail.com> wrote:
>
> >> I have a module with a type defined and a CONTAINEd subroutine with a
> >> function in its argument list, so an INTERFACE is required, as below.
> >> The ifort compiler complains with "This derived type name has not been
> >> declared." The solution would be to put the derived type in a
> >> different module and USE it, but why doesn't the interface "see" the
> >> derived type definition at the current module level? I'd really like
> >> to have the derived type together with the subroutine in one module -
> >> is it possible in some way?
>
> > Not in f95. This is quite a common complaint. It is related to a
> > decision made at the very first J3 meeting I ever attended (not yet as a
> > member) back in 1990. The original f90 standard as published said that
> > things were inherited into interface bodies. (My memory has gone hazy as
> > to whether the things in question were entity identifiers or just
> > implicit mappings, there being slightly different details involved, but
> > I think it was the larger question of identifiers, which is what you are
> > seeing).
>
> But wouldn't it still require some way to declare the type
> inside func?

No. The IMPORT statement works fine... as the OP noted.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 | 
Pages: 1
Prev: MOLD and SOURCE in an allocate statement.
Next: Identify this function?