Prev: newbie: array input
Next: Copying files
From: pmarguinaud on 25 Jun 2008 06:21
Hi all,

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.

Regards,
From: Richard Maine on 25 Jun 2008 12:58
<pmarguinaud(a)hotmail.com> 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
From: pmarguinaud on 26 Jun 2008 03:29

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...(a)see.signature (Richard Maine) wrote:
> <pmarguin...(a)hotmail.com> 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


From: Richard Maine on 26 Jun 2008 03:57
<pmarguinaud(a)hotmail.com> wrote:

> * Is the following legal:
>
> Subroutine foo
> Interface
> Subroutine foo
> End Subroutine
> End Interface
> End Subroutine

No, because that would be a duplicate specification of the interface of
foo. The interface is already known within foo. Getting sort of late
here (1 AM), so I think I'l leave finding the standard citations to
others, at least for now.

> * Is the following legal:
>
> Module bar
> Interface
> Subroutine foo
> End Subroutine
> End Interface
> End Module
> Subroutine foo
> Use bar
> End Subroutine

No, because foo is imported via the USE in a scope that already defines
it. Note that you can get around this one by using a rename clause in
the USE statement so that the foo from the module is imported with a
different local name. That workaround is fairly common. ALternatively,
you can use ONLY to restrict the names accessed via the USE, but
unfortunately, there isn't an option to USE all except for a particular
name, so this variant of the workaround sometimes needs a long ONLY
list. Again, I'll at least temporarily beg off doing the citations.

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

Same rules as any other names. Look at the clause 16 areas that I
pointed out before. Most of the stuff about name conflicts is there. In
particular, yes, a common name is allowed to be the same as a variable
name. That's one of the exceptions to the general rule against name
duplication. It is fairly common practice, when a common block has only
a single variable, to have the common block name be the same as the name
of the variable that is in the block. I don't particularly like the
practice (though I probably used it in my foolish youth), but it is a
fairly common one.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: robin on 26 Jun 2008 23:40
pmarguinaud(a)hotmail.com wrote in message
<377108db-3905-498c-b82e-7a596de9dec2(a)m3g2000hsc.googlegroups.com>...

>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.

Not in the same procedure etc.


 |  Next  |  Last
Pages: 1 2
Prev: newbie: array input
Next: Copying files