USE, ONLY question

Is it standard Fortran for an entity to appear twice in an ONLY list,
for example

module foo_mod
implicit none
integer, parameter :: one = 1
end module foo_mod

program xfoo
use foo_mod, only: one,one
print*,one
end program xfoo

I was doing this by accident in long ONLY lists, and none of the
compilers complained.

beliav...@aol.com wrote:
> Is it standard Fortran for an entity to appear twice in an ONLY list,
> for example
> I was doing this by accident in long ONLY lists, and none of the
> compilers complained.

as far as I know this is standard Fortran, but a compiler on DEC
generates an error for this.

Cheers,

Joost

<beliavsky@aol.com> wrote in message
news:1146597177.203719.9460@i40g2000cwc.googlegrou ps.com...
> Is it standard Fortran for an entity to appear twice in an ONLY list,
> for example
>
It's OK. See Note 11.7 of f95.

Regards,

Mike Metcalf

<beliavsky@aol.com> wrote:

> Is it standard Fortran for an entity to appear twice in an ONLY list,
....
> I was doing this by accident in long ONLY lists, and none of the
> compilers complained.

I would guess that it is not standard-conforming, but I admit that I'm
having a hard time finding a prohibition that is completely unambiguous.

You can definitely have the same use-name appear multiple times if each
one gives it a different local-name. Note 11.9 explains that. But the
harder question is whether it is ok to have the same local-name
specified multiple times. With the non-rename form you showed in your
example, the local-names are the same as the use-names.

I might try to cite the para after Note 11.9, which prohibits
respecification of attributes, but that para prohibits such
respecification in "other" statements. This leads me to conclude that

use foo_mod, only: one
use foo_mod, only: one

is disallowed, but it doesn't appear to apply to respecification in the
same statement. I would find that a surprising distinction, but...
sometimes surprising things are true.

I would expect c508 to apply.

"c508 An entity shall not be explicitly given any attribute more than
once in a scoping unit."

That is a very broad constraint; although it is in chapter 5, it is
phrased broadly and is not linked to particular syntax (in particular,
it definitely apples to both type declaration statements and attribute
specification statements). C508 is what prohibits things like

real :: x, x

which I think is pretty much the same issue. But this assumes that the
USE statement constitutes a way of explicitly giving attributes, which
is probably debatable.

J3 has beeen (in my opinion) inconsistent about when redundant
declarations are and are not allowed, so I'm reluctant to stand too
firmly on the general principle, lest I loose my footing. :-) But my
personal inclination is that c508 should apply here. If that is so, then
a compiler would be required to diagnose a violation of it, because c508
is a constraint.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Michael Metcalf <michaelmetcalf@compuserve.com> wrote:

> <beliavsky@aol.com> wrote in message
> news:1146597177.203719.9460@i40g2000cwc.googlegrou ps.com...
> > Is it standard Fortran for an entity to appear twice in an ONLY list,
> > for example
> >
> It's OK. See Note 11.7 of f95.

That's the same one I cited (numbered 11.9 in f2003), but it appears to
be addressing the question of multiple renames. The note does say that
there is no prohibition against a use-name appearing multiple times, but
I take that as meaning that there is no special prohibition, as long as
other requirements are met. But I don't see this as overriding c508 and
the para after note 11.9 in f2003 (or corresponding things in f95).
Having different local-names avoids those matters.

I end up getting the opposite conclusion from you, though I admit some
uncertainty in that.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

I think prohibition of having a variable isn't a good idea. Consider
the following examples:

MODULE M1
INTEGER :: I
END MODULE M1
MODULE M2
USE M1, ONLY : I
END MODULE M2

MODULE M3
USE M1
USE M2
END MODULE M3

MODULE M4
USE M1, ONLY : I
USE M2, ONLY : I
END MODULE M4

MODULE M5
USE M1
CONTAINS
SUBROUTINE S1
USE M2
END SUBROUTINE
END MODULE M5

would M3 be 'valid' whereas M4 is not ? It would really get confusing.
I guess that the answer is that a use statement doesn't provide an
attribute.

However, concerning c508, what about :

IMPLICIT INTEGER (I)
INTEGER :: I
END

Joost

Joost <jv244@cam.ac.uk> wrote:

> However, concerning c508, what about :
>
> IMPLICIT INTEGER (I)
> INTEGER :: I
> END

See the word "explicitly" in c508. This is one reason it is there. This
is unambiguously ok; there are even specific words in the standard about
type declarations that "confirm" the implicit type.

The SAVE attribute is another case. In

integer, save :: i = 42

the initialization implicitly specifies the SAVE attribute, which is
also specified explicitly. (You can also break this statement appart
into separate type declaration, data, and save statements, with the sam
eresults).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard E Maine <nospam@see.signature> wrote:
> Michael Metcalf <michaelmetcalf@compuserve.com> wrote:

>> <beliavsky@aol.com> wrote in message
>> news:1146597177.203719.9460@i40g2000cwc.googlegrou ps.com...
>> > Is it standard Fortran for an entity to appear twice in an ONLY list,
>> > for example

>> It's OK. See Note 11.7 of f95.

> That's the same one I cited (numbered 11.9 in f2003), but it appears to
> be addressing the question of multiple renames. The note does say that
> there is no prohibition against a use-name appearing multiple times, but
> I take that as meaning that there is no special prohibition, as long as
> other requirements are met. But I don't see this as overriding c508 and
> the para after note 11.9 in f2003 (or corresponding things in f95).
> Having different local-names avoids those matters.

It is interesting that multiple compilers accept it, except for DEC.
(Are they still writing compilers?) That would seem to indicate
that multiple people reading the standard believe it is allowed.
(Or they just didn't notice.)

I have known in the past DEC compilers to be overly strict on standards,
specifically not accepting C's commutative subscript operator.

In C, A[i] and I[A], with array A and integer I, are equivalent.
Due to the commutative nature of addition both are equivalent to
*(A+I) or *(I+A). The DEC C compliler didn't believe it.

-- glen

glen herrmannsfeldt <gah@upchuck.ugcs.caltech.edu> wrote:

> I have known in the past DEC compilers to be overly strict on standards,
> specifically not accepting C's commutative subscript operator.

I've never used their C compiler, but my personal impression of their
Fortran one is exactly the opposite. I consider its single biggest flaw
to be that it accepted lots of nonstandard code without even a warning
with default settings. Yes, there tend to be options to get warnings; in
my experience, that typically means that you can show someone after the
fact that the compiler could have helped them - but the people who most
need the help don't know to ask the compiler for it.

I did consider it overall a high quality compiler, but I find it odd
that we have exactly the opposite impressions in regards to DEC's degree
of pickiness about standards. Or then, perhaps it is a difference
between their C and Fortran compilers instead of a difference between
your and my impressions.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

> I would expect c508 to apply.
>
> "c508 An entity shall not be explicitly given any attribute more than
> once in a scoping unit."
>
> That is a very broad constraint; although it is in chapter 5, it is
> phrased broadly and is not linked to particular syntax (in particular,
> it definitely apples to both type declaration statements and attribute
> specification statements). C508 is what prohibits things like
>
> real :: x, x
>
> which I think is pretty much the same issue. But this assumes that the
> USE statement constitutes a way of explicitly giving attributes, which
> is probably debatable.

Yea, that's where I'd say the argument goes awry. I don't see a USE
statement as applying attributes to a symbol. Rather, you're setting
up a use-association of an entity that is already defined elsewhere.

Andy

"Richard E Maine" <nospam@see.signature> wrote in message
news:1hepo5r.163tx9l1bgyp7hN%nospam@see.signature. ..
> Michael Metcalf <michaelmetcalf@compuserve.com> wrote:
>
>> <beliavsky@aol.com> wrote in message
>> news:1146597177.203719.9460@i40g2000cwc.googlegrou ps.com...
>> > Is it standard Fortran for an entity to appear twice in an ONLY list,
>> > for example
>> >
>> It's OK. See Note 11.7 of f95.
>
> That's the same one I cited (numbered 11.9 in f2003), but it appears to
> be addressing the question of multiple renames. The note does say that
> there is no prohibition against a use-name appearing multiple times, but
> I take that as meaning that there is no special prohibition, as long as
> other requirements are met. But I don't see this as overriding c508 and
> the para after note 11.9 in f2003 (or corresponding things in f95).
> Having different local-names avoids those matters.
>
Well, the note says that there is no prohibition against a use-name
appearing multiple times in one statement. I don't see that c508 or the para
after 11.7 (11.9) are really relevant as no attribute is involved. We get to
use-name from only-list, so that looks OK too. And, no harm is done.

Regards,

Mike Metcalf

Richard E Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@upchuck.ugcs.caltech.edu> wrote:

>> I have known in the past DEC compilers to be overly strict on standards,
>> specifically not accepting C's commutative subscript operator.

> I've never used their C compiler, but my personal impression of their
> Fortran one is exactly the opposite. I consider its single biggest flaw
> to be that it accepted lots of nonstandard code without even a warning
> with default settings. Yes, there tend to be options to get warnings; in
> my experience, that typically means that you can show someone after the
> fact that the compiler could have helped them - but the people who most
> need the help don't know to ask the compiler for it.

Maybe it is the difference between Fortran and C. I used the DEC
PDP-10, PDP-11 and VAX/VMS Fortran compilers for many years, and
yes they had a lot of non-standard extensions, though usually
well documented. My understanding at the time was that it was
to give people a reason to switch from the competition (IBM).

> I did consider it overall a high quality compiler, but I find it odd
> that we have exactly the opposite impressions in regards to DEC's degree
> of pickiness about standards. Or then, perhaps it is a difference
> between their C and Fortran compilers instead of a difference between
> your and my impressions.

I didn't use the VAX C compiler all that much (though I now have
a MicroVAX with VMS and many compilers). I would say that C compilers
usually don't have many extensions, though partly that is that C is
a much simpler language. The GNU C compiler has a fair number
of non-standard features, but most others don't, long long as a 64
bit integer data type being a fairly common exception. Also, my example
was a standard feature that the compiler didn't accept.

I would say that undocumented extensions should be considered
differently from documented, even if very non-standard, extensions.

-- glen

glen herrmannsfeldt wrote:

> It is interesting that multiple compilers accept it, except for DEC.
> (Are they still writing compilers?)

DEC doesn't exist anymore as a company. But a lot of DEC Fortran
compiler engineers now work for Intel and we're still writing compilers.
Current Intel Fortran compilers accept the code in question. I don't
know how old the compiler was that Joost used - though if it called
itself a "DEC" compiler, it would have to be at least six and a half
years old.

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

Richard E Maine wrote:
> <beliavsky@aol.com> wrote:
>
> > Is it standard Fortran for an entity to appear twice in an ONLY list,
> ...
> > I was doing this by accident in long ONLY lists, and none of the
> > compilers complained.
>
> I would guess that it is not standard-conforming, but I admit that I'm
> having a hard time finding a prohibition that is completely unambiguous.
>
> You can definitely have the same use-name appear multiple times if each
> one gives it a different local-name. Note 11.9 explains that. But the
> harder question is whether it is ok to have the same local-name
> specified multiple times. With the non-rename form you showed in your
> example, the local-names are the same as the use-names.
>
> I might try to cite the para after Note 11.9, which prohibits
> respecification of attributes, but that para prohibits such
> respecification in "other" statements. This leads me to conclude that
>
> use foo_mod, only: one
> use foo_mod, only: one
>
> is disallowed, but it doesn't appear to apply to respecification in the
> same statement. I would find that a surprising distinction, but...
> sometimes surprising things are true.
>
> I would expect c508 to apply.
>
> "c508 An entity shall not be explicitly given any attribute more than
> once in a scoping unit."
>
> That is a very broad constraint; although it is in chapter 5, it is
> phrased broadly and is not linked to particular syntax (in particular,
> it definitely apples to both type declaration statements and attribute
> specification statements). C508 is what prohibits things like
>
> real :: x, x
>
> which I think is pretty much the same issue. But this assumes that the
> USE statement constitutes a way of explicitly giving attributes, which
> is probably debatable.
>
> J3 has beeen (in my opinion) inconsistent about when redundant
> declarations are and are not allowed, so I'm reluctant to stand too
> firmly on the general principle, lest I loose my footing. :-) But my
> personal inclination is that c508 should apply here. If that is so, then
> a compiler would be required to diagnose a violation of it, because c508
> is a constraint.

Section 11.2.1 of the Fortran 2003 standard states

More than one USE statement for a given module may
appear in a scoping unit. If one of the USE statements
is without an ONLY qualifier, all public entities in the
module are accessible. If all of the USE statements
have ONLY qualifiers, only those entities in one or more

^^^ ^^ ^^^^
of the only-lists are accessible.

That statement seems to say that

USE FOO_MOD, ONLY: ONE
USE FOO_MOD, ONLY: ONE

is allowed, in which case, I see no reason to suppose

USE FOO_MOD, ONLY: ONE, ONE

is prohibited.

Bob Corbett

<robert.corbett@sun.com> wrote:

> Section 11.2.1 of the Fortran 2003 standard states
>
> More than one USE statement for a given module may
> appear in a scoping unit. If one of the USE statements
> is without an ONLY qualifier, all public entities in the
> module are accessible. If all of the USE statements
> have ONLY qualifiers, only those entities in one or more
>
> ^^^ ^^ ^^^^
> of the only-lists are accessible.
>
> That statement seems to say that
>
> USE FOO_MOD, ONLY: ONE
> USE FOO_MOD, ONLY: ONE
>
> is allowed,

I don't read it that way. I believe that, just as in the case of Note
11.9, the "or more" bit refers to the possibility of a single entity
being accessible by more than one name. That is

use foo_mod, only: one
use foo_mod, only: same_one=>one

is allowed. In this case, the module entity appears in more than one of
the statements. This case is "certainly" allowed and is the subject of
Note 11.9

> in which case, I see no reason to suppose
>
> USE FOO_MOD, ONLY: ONE, ONE
>
> is prohibited.

I was thinking of a similar comparison in the opposite direction. SInce
the prohibition against having an "other" statement respecify the
attributes seems to be to prohibit the case with 2 separate USE
statements, I'd find it odd that the same thing would be allowed if it
were merged into a single statement.

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