Can a procedure know its own specific interface?

[Sebastien Bardeau]

Dear all,

please consider the following program:

module myinterfaces
interface
subroutine mysub()
end subroutine mysub
end interface
end module myinterfaces
!
program test
use myinterfaces
call mysub()
end program test
!
subroutine mysub()
use myinterfaces
end subroutine mysub

the key point here is that the specific interface of the subroutine
mysub is use-associated in the subroutine mysub itself.

My exact question is: is this standard or not? You may have your
personal feeling, but what I first want to know is what the standard
says (or do not say) about this. I can argue in a second time why I need
such a program.

I can give a hint. Look at class (1) entities in section 16.2 of the
Fortran 2003 standard: specific interfaces are not in the list of
entities whose name can conflict with i) local entity names or ii)
global entity names used in that scoping unit. Do I miss something else?

Thanks for your help,

Sebastien

[Ian Harvey]

On 29/11/2011 8:36 PM, Sebastien Bardeau wrote:
> Dear all,
>
> please consider the following program:
>
> module myinterfaces
> interface
> subroutine mysub()
> end subroutine mysub

This provides an explicit interface for mysub.

> end interface
> end module myinterfaces
> !
> program test
> use myinterfaces
> call mysub()
> end program test
> !
> subroutine mysub()

This also provides an explicit interface for mysub inside the scope of
mysub. A procedure always knows its own interface.

> use myinterfaces

This makes the first interface defined for mysub available in this
scope. Now we have two in the same scope.

> end subroutine mysub
>
> the key point here is that the specific interface of the subroutine
> mysub is use-associated in the subroutine mysub itself.
>
> My exact question is: is this standard or not? You may have your
> personal feeling, but what I first want to know is what the standard
> says (or do not say) about this. I can argue in a second time why I need
> such a program.

F2008 12.4.3.2p7 - "A procedure shall not have more than one explicit
specific interface in a given scoping unit...". Uh oh...

[Sebastien Bardeau]

Le 11/29/2011 11:49 AM, Ian Harvey a écrit :
> On 29/11/2011 8:36 PM, Sebastien Bardeau wrote:
>> Dear all,
>>
>> please consider the following program:
>>
>> module myinterfaces
>> interface
>> subroutine mysub()
>> end subroutine mysub
>
> This provides an explicit interface for mysub.
>
>> end interface
>> end module myinterfaces
>> !
>> program test
>> use myinterfaces
>> call mysub()
>> end program test
>> !
>> subroutine mysub()
>
> This also provides an explicit interface for mysub inside the scope of
> mysub. A procedure always knows its own interface.
>
>> use myinterfaces
>
> This makes the first interface defined for mysub available in this
> scope. Now we have two in the same scope.

OK but...

> F2008 12.4.3.2p7 - "A procedure shall not have more than one explicit
> specific interface in a given scoping unit...". Uh oh...

This ***F2008*** rule makes sense in conjunction of the F2008
submodules, since in that standard things are a bit more clarified. What
about F2003?


Now here is the real situation: we have thousands of subroutines, used
here and there in the same thousands of subroutines. This is inherited
from our Fortran-77 based programs.

At some point we realised that providing explicit interfaces to all of
them will help us to debug and maintain the code (i.e. detect errors in
calling sequences).

So we wrote a separate module which gathers all the interfaces of our
subroutines (the code is duplicated). This module is then used
everywhere. This worked fine with ifort and gfortran until recently, but
now gfortran breaks this.

What should we do now? What did the Fortran comittee has thought to
solve this real testcase? What are the specific interfaces made for if
they just can not be used at large scale? What do people who are
maintaining and smoothly upgrading their code should do?

One more precision: the subroutines are actually divided in several
libraries, each library defining private (for its own) and public entry
points (for Fortran-based or C-based libraries). Not sure this
accomodates well with CONTAIN'ed subroutines...

[Wolfgang Kilian]

Just an idea: USE the module in the stand-alone procedures as you do
now, but in each USE clause, rename the interface of the current host
routine, as in

subroutine foo
use interfaces, dont_use => foo
! ...
end subroutine foo

This should be rather simple to insert automatically with some scripting.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[m_b_metcalf]

On Nov 29, 8:45 pm, Sebastien Bardeau <bard...@no.domain> wrote:
>
> Now here is the real situation: we have thousands of subroutines, used
> here and there in the same thousands of subroutines. This is inherited
> from our Fortran-77 based programs.
>

The situation you describe appears in Section 7.10 of MFE (or MR&C).
The solution, as mentioned there, is to rename, in each procedure, the
relevant interface with a spurious name.

Regards,

Mike Metcalf

[Sebastien Bardeau]

Le 11/29/2011 01:28 PM, m_b_metcalf a �crit :

This is indeed the solution we had in mind, and that we will probably
choose.

But this sounds to me more than an ad-hoc patch to compensate a failure
in the Standard definition, rather than a thoughtful way to proceed in
the context I described. Just my end-user point of view.

However thanks everyone for your help.

[Ian Bush]

Sorry, pet peeve:

On 29/11/11 14:13, Sebastien Bardeau wrote:
> ad-hoc

It's ad hoc, no hyphen. Whatever happened to a classical education?

Ian

[Richard Maine]

Sebastien Bardeau <bar...@no.domain> wrote:

My personal opinion is that pretty much everything about external
Fortran procedures is a hack. This is far from the only messy feature of
them. I recommend avoiding them to the extent practical in new code. I
realize that legacy code is inevitably full of external procedures, that
having been the only option for a long time. But using that legacy code
is never going to be as clean as newly done code can be.

The Fortran standard goes to a lot of trouble to make it possible to mix
old and new code, but that does sometimes result in pretty strange
messes. In my opinion, some of the messiest parts of the standard relate
to how old and new features mix. It could be much cleaner if redesigned
anew... but it also wouldn't have any users. :-(

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

[Sebastien Bardeau]

Dear all,

is this also illegal?

module myinterfaces
interface mysub
subroutine mysub_real(r)
real(kind=4) :: r
end subroutine mysub_real
subroutine mysub_inte(i)
integer(kind=4) :: i
end subroutine mysub_inte
end interface mysub

end module myinterfaces
!
program test
use myinterfaces

call mysub(1)
end program test
!
subroutine mysub_real(r)
use myinterfaces
real(kind=4) :: r
end subroutine mysub_real
!
subroutine mysub_inte(i)
use myinterfaces
integer(kind=4) :: i
end subroutine mysub_inte


gfortran 4.7.0-20111119 complains here also about conflicting names,
which means that all the specific interfaces in the generic interface
are also made available by use-association. I would have expect them to
be hidden (i.e. not accessible). Does this also mean that I can not
define at the same time a specific interface to e.g. mysub_real AND a
generic interface e.g. mysub using this specific interface?

[Richard Maine]

Yes, that is also illegal, but no, your conclusion is incorrect.

I'm not sure why you would expect the specific names to be inaccessible.
You do, after all, have the module default accessibility at public,
which means that everything in it is accessible unless declared
otherwise. That includes interfaces. The fact that these happen to also
be specific procedures in a generic is a minor detail that doesn't
change this.

I personally think it was a mistake in the standard to combine the
functionality of defining specific interfaces with that of defining
generics. It causes several kinds of confusion, along with one notable
flaw in the f90/f95 standard, which was rectified in f2003. Looks to me
like you got caught up in one of the confusions. Your example defines
specific interfaces for mysub_real and mysub_inte, just like a simillar
example with no generic would have done. One would certainly expect
those specific interfaces to be accessible, that being the whole point
of one major way of using interface bodies. Your example *ALSO* defines
a generic, but note my emphasis on the "also". That's an additional
thing that it does, but that doesn't take away the fact that it defines
specific interfaces.

If you don't want the specific names to be public, then make them
private. And remember that the default is that everything in a module is
public. I normally override that default with a PRIVATE statement and
then explicitly declare as public only those particular things that I
want to be public.

Doing that with your example above by adding the lines

public
private :: mysub

at the top of the module makes g95 happy anyway. The version of gfortran
I have on this machine seems to compile even your original without
complaint, though I'd consider that a bug. (It is an older version of
gfortran, looks like 4.5.1).

[Sebastien Bardeau]

Ok, so if I say it a bit differently, a generic interface block is first
an interface block which provides the specific interfaces defined in it.
The fact that a generic interface also adds a new callable identifier
comes next.

This seems fine to me, although my first feeling was that generic
interfaces were a bit like derived types, i.e. even if I define elements
in it, there is no direct access to these elements.

My exact worry was about the behaviour of the various compilers
regarding this code.

> If you don't want the specific names to be public, then make them
> private. And remember that the default is that everything in a module is
> public. I normally override that default with a PRIVATE statement and
> then explicitly declare as public only those particular things that I
> want to be public.
>
> Doing that with your example above by adding the lines
>
> public
> private :: mysub
>
> at the top of the module makes g95 happy anyway. The version of gfortran
> I have on this machine seems to compile even your original without
> complaint, though I'd consider that a bug. (It is an older version of
> gfortran, looks like 4.5.1).

Indeed I came with my very first post a few days ago because gfortran
fixed recently their behavior regarding specific interface conflicts.

Thanks for your answer.

[Richard Maine]

Sebastien Bardeau <bar...@no.domain> wrote:

> Ok, so if I say it a bit differently, a generic interface block is first
> an interface block which provides the specific interfaces defined in it.
> The fact that a generic interface also adds a new callable identifier
> comes next.

Yes. Precisely.

> This seems fine to me, although my first feeling was that generic
> interfaces were a bit like derived types, i.e. even if I define elements
> in it, there is no direct access to these elements.

I can see how one might get that impression, but one would be wrong.
That's part of the confusion I was referring to.

> My exact worry was about the behaviour of the various compilers
> regarding this code.

That might be a trickier question. I can only answer to what the
standard requires (or more precisely, my interpretation of what the
standard requires). I recall vaguely simillar cases (not necessarily
this exact one, and I can't recall well enough to cite the details)
where some compiler let things that ought to have been private "slip
out" enough to cause conflicts that shouldn't have been a problem.
That's part of why I tested my suggestion (that and it was easy to do
so). I could imagine compilers failing even with the PRIVATE
declaration; that would be a compiler bug, but that doesn't mean it
never happens. WIthout the PRIVATE declaration, the code is illegal and
it counts as a bug for a compiler to not at least be able to diagnose
it. (Anyway, I think it would fall in the category of things where the
standard requires diagnostic capability; I'd call it a bug to compile
the code without warning even if the standard doesn't require
diagnosis).

[Erik Toussaint]

On 1-12-2011 10:57, Richard Maine wrote:
> Doing that with your example above by adding the lines
>
> public
> private :: mysub

Early morning, or late night? ;)
I'm pretty sure you meant:

private
public :: mysub

[Richard Maine]

Yes, that was about 2 AM. And yes, you are, of course, correct about
what I meant. You prompted me to check... yes, I did it correctly in the
code that I tested.