[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-23 16:51:39 UTC ---
(In reply to comment #4)
> So basically you mean that in the gfortran implementation the subroutine name
> is part of the scope this subroutine defines (which forbids any other entity
> declared with the same identifier). Is this standard?

Yes. It gets more obvious if you consider a function:
  function f()
    integer :: f
thus, the "f" needs to be part of the body of the function.

It should be buried in "16 Scope, association, and definition", but I need some
time to extract it. You could also ask at the comp.lang.fortran newsgroup where
(among others) the editor of the Fortran 2003 standard answers such questions.


> From my view, a subroutine and an interface are not just orthogonal objects
> which should conflict because they have the same name.

Instead of an interface, consider:
  module m
    external sub
  end module m

  recursive subroutine sub()
    use m
    call sub()
  end subroutine sub

This is equivalent to:

  recursive subroutine sub()
    external sub
    call sub()
  end subroutine sub

Thus, you specify that some external subroutine "sub" exists ("external sub")
but at the same time you are in the subroutine. Thus, you have somehow either
specified the same subroutine twice or two different ones, which have the same
name. It looks odd, it looks wrong - and the committee has decided that it is
invalid.

That it is invalid does not mean that one cannot implement it, it also does not
mean that there is no usage case for it; it just means that either they did not
come up with the usage case - or thought that it is the wrong solution to the
problem. In this case, I think it is the latter.


> In an ideal world, the
> compiler would assume the interface "foo" refers to the subroutine "foo", and
> the compiler will have by the way the possibility to check if they are
> consistent...

In an ideal world there is no need to use an INTERFACE block at all as the
interface is automatically available if the procedure is in a module or an
internal procedure. As written, the committee has realized that the previous
concept is insufficient and added around 2003 (ISO publication: 2005) a
technical report to solve this problem: submodules.


[Submodules]
> We support a large range of systems and we can not yet consider this solution
> as long as it is not widely supported by the compilers...

Well, as I wrote that's the idea of the committee. Many expected that it would
be quickly implemented - much earlier than the rest of Fortran 2003. However,
it seems to be one of the features which gets implemented very late - one of
the last Fortran 2008 features! Given that currently only crayftn supports it,
I also do not recommend its use.


> > (In reply to comment #2)
> > Well, you could use multiple modules for the actual implementation and then
> > collect all of them in
> >   module master
> >     use m1
> >     use m2
> >     ...
> >   end module master
> 
> I am not sure to understand what you suggest to put in the modules m1, m2 etc:
> the interfaces only or the subroutines themselves?

The subroutines themselves. That avoids having the whole library in a single
file; it also avoid to write an interface for all the procedures. There is a
down side: If you need the library available without "USE module" in a Fortran
77 like fashion or if you do not want to release the source code, it won't
work. (For the former case, one should consider C bindings.) Whether this
proposal is a good solution for your problem, I don't know, but it is a Fortran
95 solution for (part of) your problem.