Re: Question about name conflicts in Fortran


Hello,

I am really impressed by your knowledge and understanding of the
standard...
I am hacking the g95 compiler so that it dumps the structure
( statements, expressions, symbols, etc... ) in XML format. I have
very good results, but I am currently improving that so I have to go
down to the lowest details of Fortran.

My homepage is http://g95-xml.sourceforge.net/.

I have other weird questions about Fortran...

* Is the following legal:

Subroutine foo
Interface
Subroutine foo
End Subroutine
End Interface
End Subroutine

( I have not been able to find the answer in the standard, and some
compilers accept it )

* Is the following legal:

Module bar
Interface
Subroutine foo
End Subroutine
End Interface
End Module
Subroutine foo
Use bar
End Subroutine

* Is there a restriction on common names ? Should their name be
different from local variables ?




Best regards,


Philippe







On Jun 25, 6:58 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
<pmarguin...@xxxxxxxxxxx> wrote:
I have a question about the name collisions between generics and
procedures in Fortran. I would like to know whether a generic is
allowed to have the same name as a non-related subroutine.
I have looked in the ISO-1539 but could not find the relevant
constraint. Please tell me where it is if you known it.

There needs to be slightly more precise specification to give the right
answer. In particular, it matters whether the "non-related" subroutine
name is used in the same scoping unit. A generic name is a local
identifier - not a global one. So if the unrelated subroutine is used
only in different scoping units, then there is no conflict. I'm guessing
that's not what you are talking about, but I can't tell for sure and it
is an important point, at least if one is writing compilers. (If one is
writing Fortran code, my advice is to just not do it anyway; one doesn't
actualy have to do every possibly thing to confuse readers and
compilers, just because the standard allows it).

If you are talking about within the same scoping unit then the answer is
"no". There are two ways to deduce this.

1. The answer pretty much has to be "no". Either that or there would
need to be a complicated set of special-case rules big enough that you
could not possibly miss them. :-) If you invoke a procedure of that
name, the compiler needs to know whether it is the generic or the
unrelated subroutine. If the subroutine were a specific in the generic,
then things would all work out because the generic resolution rules will
always get you that specific anyway in the cases where it fits. If the
subroutine is not one of the specifics in the generic (I assume that's
what you mean by "non-related"), then there would be ambiguity about
whether the generic or the unrelated subroutine was intended. Resolving
this would take a complicated set of extra rules..... which don't exist.

2. The standard does say this, though I see one bit of wording that is
confusingly incomplete. Most of this kind of thing is in clause 16.2,
"Scope of local identifiers".

Working backwards in 16.2, because the simpler cases are the last ones:
The last para in the section (with the 3rd numbered list) is the one
that says (in short) that you can reuse the same local name as long as
you are in a different scoping unit. That's what I referred to in
talking about yhe case where the unrelated subroutine was used only in
different scoping units.

The para after the 2nd numbered list in 16.2 covers the case where the
unleated subroutine name is a local name (i.e. when it is any kind of a
procedure except for an external one, and even an external procedure can
have a local name if accessed via USE). That para is the one that says
(in short) that two local things can't have the same identifier, with
some exceptions. One of the exceptions is "a generic name may be the
same as the name of a procedure as explained in 12.3.2.1" In 12.3.2.1,
near the end, in the para that starts "A generic name specifies...", you
can find the case, which is that the generic name may be the same as one
of the procedure names in the interface block.

The para that includes the 2nd numbered list covers the case where the
unrelated subroutine name is a global name (i.e. it is an external
procedure not accessed via USE). Again, that mostly says that name
conflicts aren't allowed, with a few exceptions. List item 2 is the
exception for an external procedure name being the same as a generic
name. Unfortunately, it fails to cite 12.3.2.1 and thus could be read as
applying without qualification, which would allow "too much".

That failure to cite 12.3.2.1 appears to me to be a mistake in the
standard's wording (because, as I noted above, that pretty much can't
work - besides which, it would be exceedingly odd for this rule to
differ depending on whether it was a global name or a local one). I'm
betting that when the reference to 12.3.2.1 was added to the following
para, someone forgot to notice that it didn't explicitly qualify to this
list item as well without additional words to say so. This area of the
standard used to have more of that kind of vague exception, where it
said there was an exception, but failed to qualify it adequately.
Several of them got fixed, but it looks to me like someone failed to
notice that the fix for generic and specific names needed to be applied
in two places.

But again, if you are a programmer, for heaven's sake, just don't do it
- either in the case where it clearly is allowed (different scoping
units) or in the case where the sloppy wording of the standard might
appear to allow more than I think was intended. If you are writing a
compiler, your life is harder.

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


.

Relevant Pages

  • Re: IFC Floating Point Behavior
    ... > Does anyone know if there is a way to get IntelFortran Compiler ... then call the subroutine ftrap_common at the start of your ... Turns on exceptions for common FP violations ... subroutine system(command, ierror) ...
    (comp.lang.fortran)
  • Re: DPROD issues
    ... a switch like that typically ... makes a compiler nonstandard in that mode. ... treatment of specific intrinsics is one ... subroutine sub1a ...
    (comp.lang.fortran)
  • Re: Jumping into block of an if construct
    ... (For that matter a clever enough compiler could replace this PUT DATA ... routine which itself executes the loops around element handling. ... Either way I think the cost of element handling will usually ... So locally based on subroutine arguments, but not on, for example, ...
    (comp.lang.fortran)
  • Re: Bus error/ segmentation fault--help?
    ... When I compile with the intel fortran compiler, ... This subroutine integrates the function y3 up one step, ... implicit double precision (a-h, o-z) ...
    (comp.lang.fortran)
  • Re: using dot_product from c++
    ... I tried to write a very simple subroutine where two vector are dot ... Assumed shape arrays are incompatible with mixed language use unless you code explicitly for the descriptor on the other side, which will be highly nonportable (even from one version of a compiler to another, let alone from one compiler to another). ... You should either not initialize the vectors or you should not use push_back but instead reference the location you wish to access directly. ... I guess maybe it arises because the misunderstandings between the codes multiply to put the memory manager out of whack. ...
    (comp.lang.fortran)