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

Richard Maine wrote:

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

Do you think the program

      MODULE M0
        INTEGER I
        DATA I/2/
      END

      MODULE M1
        USE M0
      END

      MODULE M2
        USE M0
      END

      PROGRAM MAIN
        USE M2
        USE M2
        PRINT *, I
      END

is standard conforming?

Bob Corbett

robert.corb...@sun.com wrote:
> Richard Maine wrote:
>
> > 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.
>
> Do you think the program
>
>       MODULE M0
>         INTEGER I
>         DATA I/2/
>       END
>
>       MODULE M1
>         USE M0
>       END
>
>       MODULE M2
>         USE M0
>       END
>
>       PROGRAM MAIN
>         USE M2
>         USE M2
>         PRINT *, I
>       END
>
> is standard conforming?

Please replace the first

      USE M2

in MAIN with

      USE M1

Bob Corbett

Richard Maine wrote:

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

Do you think the program

      MODULE M0
        INTEGER I
        DATA I/2/
      END

      MODULE M1
        USE M0
      END

      MODULE M2
        USE M0
      END

      PROGRAM MAIN
        USE M1
        USE M2
        PRINT *, I
      END

is standard conforming?

Bob Corbett

 > Or then, perhaps it is a difference between their C and Fortran
 > compilers instead of a difference between your and my impressions.

VAX C was a design derived by reading the literature, a standard being
non-existent at the time. The resulting implementation suffered a lot
from being very idiosyncratic, because it didn't have the historical
background of other implementations. Did I already say there wasn't any
agreed standard the VMS could rely on? So they got a lot of things "wrong",
in some sense of the word, and the low priority C had within DEC and VMS
at the time did nothing to improve things.

But that is history, and for more than a decade I do think the DEC C com-
pilers have been quality products. But C and Fortran within DEC certainly
had very different histories and developments.

	Jan

If this code is not Standard conforming, than all comilers that
I have access to (Salford, Lahey, CVF, Intel, PathScale,
Open Source g95, Absoft, and Portland) fail to diagnose
a violation of the Standard:-)

Skip Knoble

On 2 May 2006 20:53:00 -0700, robert.corbett@sun.com wrote:

-|
-|Richard Maine wrote:
-|
-|> 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.
-|
-|Do you think the program
-|
-|      MODULE M0
-|        INTEGER I
-|        DATA I/2/
-|      END
-|
-|      MODULE M1
-|        USE M0
-|      END
-|
-|      MODULE M2
-|        USE M0
-|      END
-|
-|      PROGRAM MAIN
-|        USE M1
-|        USE M2
-|        PRINT *, I
-|      END
-|
-|is standard conforming?
-|
-|Bob Corbett

<robert.corbett@sun.com> wrote:

> Richard Maine wrote:
> 
> Do you think the program
> 
>       MODULE M0
>         INTEGER I
>         DATA I/2/
>       END
> 
>       MODULE M1
>         USE M0
>       END
> 
>       MODULE M2
>         USE M0
>       END
> 
>       PROGRAM MAIN
>         USE M1
>         USE M2
>         PRINT *, I
>       END
> 
> is standard conforming?

Yes. Pretty certain of that one, in fact. There was a time long ago when
it was controversial, or anyway some compilers got it wrong, but there
was an interp on the matter. That was one of the early f90 interps, as I
recall. Not worth digging it out, as I think we "all" agree on it now.

You make a good point (by implication) in that this has similarities to
the case I have been arguing to be nonconforming, but this one is well
established to be allowed. I'm wanting to say that the explicitness of
the repetition in the ONLY clauses make them look different to me. But
perhaps the difference is only in my eye instead of in the standard.

On the other hand, there are other cases where ONLY does make a
difference in whether duplication is allowed. Specifically, f2003
[252:25-26] disallows having the same name identify two different
entities, but has an exception if the name is "not used to refer to an
entity" in the scoping unit. An appearance of the name as a local-name
in an ONLY is a "use to refer to an entity" and thus triggers the
prohibition. I realize that is not the same case as we have here. In the
case here, the name refers to the same entity (that was the essential
point made in the old f90 interp). So although it isn't identical, I
mention it to cite how having the explicit ONLY can make a difference in
some cases.

But I do find your implied argument cogent. It leans me more towards the
side of agreeing that the code in the original post of this thread is
standard conforming. I'm still not entirely convinced, but I now at
least lean slightly more to that side.

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

I'm actually not using the compiler nor the machine (I know this only
from changelog entries in our code), so I asked my co-worker some more
details:

The system is at :
Compaq Tru64 UNIX V5.1B (Rev. 2650)

The compiler is at :
        Compaq Fortran V5.5-1877
        Compaq Fortran Compiler V5.5-1877-48BBF

I'm actually not sure this is a 'DEC', but that seems to be what they
call it.

Cheers,

Joost

> The compiler is at :
>        Compaq Fortran V5.5-1877
>        Compaq Fortran Compiler V5.5-1877-48BBF

Ok, that's from 2003 or 2004.  The current version on that platform is
5.6.  I assume we changed the behavior for this usage at some point in
the past.

Steve