labels and type names
Joost
TYPE vertex
INTEGER :: k
END TYPE vertex
CONTAINS
SUBROUTINE S1()
TYPE(vertex) :: a
vertex : DO i=1,2
ENDDO vertex
END SUBROUTINE
END MODULE test
Is the above code standard conforming ? In particular can you have a
label and a type with the same like in the subroutine S1 ? G95 doesn't
error on this case, but a couple of other compilers do.
Thanks,
Joost
Richard Maine
[elided]
> Is the above code standard conforming ? In particular can you have a
> label and a type with the same like in the subroutine S1 ?
No. Both are class 1 local identifiers. Actually, almost everything is a
class 1 local identifier. See the list of them in c16.
You can't have 2 different class 1 entities with the same identifier,
with one or two special exceptions that I won't bother to quote here. In
short, the answer to almost all of the almost infinite number of
variations of "can I have an x and a y of the same name?" is "no".
There are combinations of x and y where there is no obvious syntactic
reason why it couldn't work, but the general answer still applies.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Andy
Richard Maine wrote:
> Joost <jv...@cam.ac.uk> wrote:
> [elided]
> > Is the above code standard conforming ? In particular can you have a
> > label and a type with the same like in the subroutine S1 ?
>
> No. Both are class 1 local identifiers. Actually, almost everything is a
> class 1 local identifier. See the list of them in c16.
>
> You can't have 2 different class 1 entities with the same identifier,
> with one or two special exceptions that I won't bother to quote here. In
> short, the answer to almost all of the almost infinite number of
> variations of "can I have an x and a y of the same name?" is "no".
> There are combinations of x and y where there is no obvious syntactic
> reason why it couldn't work, but the general answer still applies.
"Named constructs" are on the list in 14.6.1.3 (f95) of entities that
are excluded from host association. I originally told Joost they
were not on the list, but it looks like I was wrong. The above
argument would prohibit any host association, so it must be incomplete.
I think the code is legal...
Andy
James Giles
...> "Named constructs" are on the list in 14.6.1.3 (f95) of entities
> that are excluded from host association. I originally told Joost
> they were not on the list, but it looks like I was wrong. The above
> argument would prohibit any host association, so it must be
> incomplete. I think the code is legal...
In the original code (repeated below) host association is not
appled to the construct name. Type names *are* host associated.
Since derived type names cannot be the same as other class-one
names, the code is not legal.
MODULE test
TYPE vertex
INTEGER :: k
END TYPE vertex
CONTAINS
SUBROUTINE S1()
TYPE(vertex) :: a
vertex : DO i=1,2
ENDDO vertex
END SUBROUTINE
END MODULE test
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Richard Maine
> "Named constructs" are on the list in 14.6.1.3 (f95) of entities that
> are excluded from host association. I originally told Joost they
> were not on the list, but it looks like I was wrong. The above
> argument would prohibit any host association, so it must be incomplete.
> I think the code is legal...
I think there is some confusion here, possibly at several levels.
I think the description of the 14.6.1.3 list as being "entities that are
excluded from host association" is misleading. It is doubly misleading
in that indeed named constructs can't be usefully host associated, but
for reasons that have nothing to do with that list.
I would describe that list as the things that block host association.
That might sound similar, but the it isn't. Many of the things in that
list (although not construct labels) describe can be host associated.
But look at the list carefully. Everything in the list is a specifc
piece of syntax. It is always the specific syntax that blocks host
association - not the kind of entity referred to. For example, list item
2 says that a named constant definition in a parameter statement blocks
host association. That doesn't mean that named constants are never host
associated. It means that if you have a parameter statement in a
contained scoping unit, that blocks association of whatever else might
have otherwise been host associated with that name.
Basically, the "are excluded" is backwards. It is more like that that
these entities are the excluders instead of the excludees.
Anyway, on to the case in debate. I hadn't even paid enough attention to
the code to notice the host association right at first.I just focussed
on the question of whether you can have the 2 things of the same name.
You can't. It turns out that the host association material gives a
consistent answer here (fortunately, because otherwise it would be a bug
in the standard). Namely...
Yes, the use of the name vertex in a named construct is item 13 in the
long list of things that block host association. Therefore, by the rest
of the sentence, right after the list, vertex "any entity of the host
that has this as its nongeneric name is inacessible by that name by host
association." That is, the host association of the derived type name
vertex is blocked. Therefore, the type declaration in the contained
subroutine is invalid, as it uses a type name that is not accessible in
that scope. (I won't track down the requirement that the type name be
accessible unless you don't believe it. I take that as "obvious", though
I'm confident it is spelled out in detail anyway.)
Thus, the code is illegal in my analysis.
Andy
James Giles wrote:
> Andy wrote:
> ...> "Named constructs" are on the list in 14.6.1.3 (f95) of entities
> > that are excluded from host association. I originally told Joost
> > they were not on the list, but it looks like I was wrong. The above
> > argument would prohibit any host association, so it must be
> > incomplete. I think the code is legal...
>
> In the original code (repeated below) host association is not
> appled to the construct name. Type names *are* host associated.
> Since derived type names cannot be the same as other class-one
> names, the code is not legal.
>
> MODULE test
> TYPE vertex
> INTEGER :: k
> END TYPE vertex
> CONTAINS
> SUBROUTINE S1()
> TYPE(vertex) :: a
> vertex : DO i=1,2
> ENDDO vertex
> END SUBROUTINE
> END MODULE test
Oops, I missed the derived type declaration. I agree that the code
is illegal. I've got g95 fixed now. The fixed version will soon be at
the usual place at http://www.g95.org.
Andy