I've found what I think is a bug in (not the newest version of) Fortran 
on VMS ALPHA.  Anyone else using this?

Here is a minimal example:

MODULE BLA
INTEGER :: I=HUGE(1)
END MODULE BLA
PROGRAM TEST
USE BLA, ONLY: I, HUGE
PRINT*, I
END PROGRAM TEST

In other words, if one adds to the ONLY list in the USE statement the 
name of an intrinsic function which is used in the corresponding module, 
then no error or warning is given.  However, if the intrinsic function 
is not used in the module, or if one just has some other name, then an 
error is generated.

However, one does get an error if one tries to use the name of the 
intrinsic function as a variable name.  So, the bug looks harmless, but 
appears to be a bug nevertheless.

This is Compaq Fortran V7.5-2630-48C8L.  What is the latest version for 
ALPHA?  For Itanium?  Will any standard later than F95 ever be 
supported?

On 2012-07-29 13:25:38 +0000, Phillip Helbig---undress to reply said:

> I've found what I think is a bug in (not the newest version of) Fortran
> on VMS ALPHA.  Anyone else using this?

What OpenVMS version and what Fortran command(s) are you using?

> 
> Here is a minimal example:
> 
> MODULE BLA
> INTEGER :: I=HUGE(1)
> END MODULE BLA
> PROGRAM TEST
> USE BLA, ONLY: I, HUGE
> PRINT*, I
> END PROGRAM TEST
> 
> In other words, if one adds to the ONLY list in the USE statement the
> name of an intrinsic function which is used in the corresponding module,
> then no error or warning is given.  However, if the intrinsic function
> is not used in the module, or if one just has some other name, then an
> error is generated.
> 
> However, one does get an error if one tries to use the name of the
> intrinsic function as a variable name.  So, the bug looks harmless, but
> appears to be a bug nevertheless.

Have you tried replicating that Fortran code and that issue under a 
Fortran compiler on another platform?

$ gfortran -pedantic -Wall x.for
$ ./a.out
  2147483647
$ gfortran --version
GNU Fortran (GCC) 4.8.0 20120603 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
....
$

For whatever reason, the posted Fortran code compiles with gfortran set 
with fairly aggressive diagnostics.


> 
> This is Compaq Fortran V7.5-2630-48C8L.  What is the latest version for
> ALPHA?  For Itanium?

That'd be the first step here; look for upgrades.

Looks to be V8.2 based on the posted Fortran documentation, though the 
posted Fortran SPD is for Fortran V8.0 on Alpha and Fortran V8.1 on 
Itanium; the SPD is stale.

SPDs: http://h71000.www7.hp.com/doc/spd.html

Docs: http://h71000.www7.hp.com/doc/

You can use your preferred web search engine to answer these questions 
yourself, of course.  To this end, a reasonable Google or Bing query 
here might be:

OpenVMS fortran spd site:h71000.www7.hp.com

Bing gets the OpenVMS SPD web page as the first hit, and the Fortran 
SPD as the second hit.


> Will any standard later than F95 ever be supported?

Unlikely.  But you should ask HP for the official answer.

IIRC, Fortran is missing 2003 and 2008, C is missing C99 and C11, and 
COBOL is missing 2002 and the OO support and some TRs.


-- 
Pure Personal Opinion | HoffmanLabs LLC

In article <jv3j9j$3tf$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> > I've found what I think is a bug in (not the newest version of) Fortran
> > on VMS ALPHA.  Anyone else using this?
> 
> What OpenVMS version and what Fortran command(s) are you using?

Compaq Fortran V7.5-2630-48C8L, VMS 7.3-2

F90/ALIGN=NATURAL/ASSUME=(NOALTPARAM,MINUS0) /ERROR_LIMIT=5
/INCLUDE=(F95_LIB,MY_NR90,NR90) /STANDARD=F95/WARNINGS=ALL
/CHECK=(BOUNDS,FOR,NOFP,OUT,NOOV,POW,NOUN)

> Have you tried replicating that Fortran code and that issue under a 
> Fortran compiler on another platform?

No, hence the post here.

> $ gfortran -pedantic -Wall x.for
> $ ./a.out
>   2147483647
> $ gfortran --version
> GNU Fortran (GCC) 4.8.0 20120603 (experimental)
> Copyright (C) 2012 Free Software Foundation, Inc.
> ....
> $
> 
> For whatever reason, the posted Fortran code compiles with gfortran set 
> with fairly aggressive diagnostics.

If you change HUGE to some other intrinsic in the ONLY, do you get an 
error?  That is:

MODULE BLA
INTEGER :: I=HUGE(I)
END MODULE BLA
PROGRAM TEST
USE BLA, ONLY: I, RADIX   !RADIX throws error, HUGE doesn't
PRINT*, I
END PROGRAM TEST

Some tests indicate that as long as the bogus variable in the ONLY list 
is the same string as an intrinsic used in the specification expression 
in the module, then no error occurs, but if it is another intrinsic, or 
just some "random" variable name, then an error occurs.

It would be interesting if other platforms have the same bug.  (At 
least, I'm pretty sure it is a bug.)

On 2012-07-29 16:10:20 +0000, Phillip Helbig---undress to reply said:

> MODULE BLA
> INTEGER :: I=HUGE(I)
> END MODULE BLA
> PROGRAM TEST
> USE BLA, ONLY: I, RADIX   !RADIX throws error, HUGE doesn't
> PRINT*, I
> END PROGRAM TEST

$ gfortran -pedantic -Wall y.for
y.for:5.23:

      USE BLA, ONLY: I, RADIX   !RADIX throws error, HUGE doesn't
                       1
Error: Symbol 'radix' referenced at (1) not found in module 'bla'
$

But the following variant compiles cleanly:

      MODULE BLA
      INTEGER :: I=HUGE(I)
      INTEGER :: J=RADIX(J)
      END MODULE BLA
      PROGRAM TEST
      USE BLA, ONLY: I, RADIX
      PRINT*, I
      END PROGRAM TEST

Tried a Fortran manual or a Fortran newsgroup for the USE statement and 
environments?


-- 
Pure Personal Opinion | HoffmanLabs LLC

In article <jv3p83$6vq$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> > MODULE BLA
> > INTEGER :: I=HUGE(I)
> > END MODULE BLA
> > PROGRAM TEST
> > USE BLA, ONLY: I, RADIX   !RADIX throws error, HUGE doesn't
> > PRINT*, I
> > END PROGRAM TEST
> 
> $ gfortran -pedantic -Wall y.for
> y.for:5.23:
> 
>       USE BLA, ONLY: I, RADIX   !RADIX throws error, HUGE doesn't
>                        1
> Error: Symbol 'radix' referenced at (1) not found in module 'bla'
> $

I get the equivalent error.

> But the following variant compiles cleanly:
> 
>       MODULE BLA
>       INTEGER :: I=HUGE(I)
>       INTEGER :: J=RADIX(J)
>       END MODULE BLA
>       PROGRAM TEST
>       USE BLA, ONLY: I, RADIX
>       PRINT*, I
>       END PROGRAM TEST

Right.  As long as the bogus variable has the same name as a function 
used in the module, no error appears.

> Tried a Fortran manual or a Fortran newsgroup for the USE statement and 
> environments?

All the Fortran manuals I have read say that the ONLY list applies to 
objects (variables, parameters (named constants), routines) declared in 
the module.

The original post was crossposted to comp.lang.fortran as well.  Looks
like one of the followups, intentionally or not, posted to just
comp.os.vms, with the result that subsequent posts are here only.

In article <jv3j9j$3tf$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> > In other words, if one adds to the ONLY list in the USE statement the
> > name of an intrinsic function which is used in the corresponding module,
> > then no error or warning is given.  However, if the intrinsic function
> > is not used in the module, or if one just has some other name, then an
> > error is generated.
> > 
> > However, one does get an error if one tries to use the name of the
> > intrinsic function as a variable name.  So, the bug looks harmless, but
> > appears to be a bug nevertheless.
> 
> Have you tried replicating that Fortran code and that issue under a 
> Fortran compiler on another platform?
> 
> $ gfortran -pedantic -Wall x.for
> $ ./a.out
>   2147483647
> $ gfortran --version
> GNU Fortran (GCC) 4.8.0 20120603 (experimental)
> Copyright (C) 2012 Free Software Foundation, Inc.
> ....

For what it's worth, I get similar behaviour on:

foobar:~> gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --eu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
foobar:~> gfortran --version
GNU Fortran (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.

"Phillip Helbig---undress to reply" <helbig@astro.multiCLOTHESvax.de> wrote 
in message news:jv3dki$i4s$1@online.de...

> I've found what I think is a bug in (not the newest version of) Fortran
> on VMS ALPHA.  Anyone else using this?

> Here is a minimal example:

> MODULE BLA
> INTEGER :: I=HUGE(1)
> END MODULE BLA
> PROGRAM TEST
> USE BLA, ONLY: I, HUGE
> PRINT*, I
> END PROGRAM TEST

> In other words, if one adds to the ONLY list in the USE statement the
> name of an intrinsic function which is used in the corresponding module,
> then no error or warning is given.  However, if the intrinsic function
> is not used in the module, or if one just has some other name, then an
> error is generated.

> However, one does get an error if one tries to use the name of the
> intrinsic function as a variable name.  So, the bug looks harmless, but
> appears to be a bug nevertheless.

> This is Compaq Fortran V7.5-2630-48C8L.  What is the latest version for
> ALPHA?  For Itanium?  Will any standard later than F95 ever be
> supported?

I tried to compose an even more interesting example but both my
rather old version of ifort and recent version of gfortran
experience difficulties right off the bat, not being able to handle
a specification inquiry:

C:\gfortran\clf\implicit_mod>type implicit_mod.f90
module implicit_mod
   implicit character(kind(1.0)) (A)
   implicit real(len(ABC)) (B)
   integer :: I = huge(1)
end module implicit_mod

program test
   use implicit_mod, only: XYZ => ABC, I, LARGEISH => HUGE
   XYZ = '123456789'
   write(*,*) XYZ, I, LARGEISH(INT(1,SELECTED_INT_KIND(18)))
program test

C:\gfortran\clf\implicit_mod>ifort implicit_mod.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

implicit_mod.f90(3) : Error: A kind type parameter must be a compile-time 
consta
nt.   [LEN]
   implicit real(len(ABC)) (B)
-----------------^
implicit_mod.f90(11) : Error: Syntax error, found END-OF-FILE when expecting 
one
 of: <LABEL> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE 
CHAR
ACTER ...
program test
------------^
implicit_mod.f90(8) : Error: Error in opening the Library module file. 
[IMPLIC
IT_MOD]
   use implicit_mod, only: XYZ => ABC, I, LARGEISH => HUGE
-------^
implicit_mod.f90(11) : Error: A specification statement cannot appear in the 
exe
cutable section.
program test
^
implicit_mod.f90(9) : Error: The use-name for this local-name is not 
defined.
[XYZ]
   XYZ = '123456789'
---^
implicit_mod.f90(10) : Error: The use-name for this local-name is not 
defined.
 [XYZ]
   write(*,*) XYZ, I, LARGEISH(INT(1,SELECTED_INT_KIND(18)))
--------------^
implicit_mod.f90(10) : Error: Conflicting attributes or multiple declaration 
of
name.   [I]
   write(*,*) XYZ, I, LARGEISH(INT(1,SELECTED_INT_KIND(18)))
-------------------^
implicit_mod.f90(10) : Error: The use-name for this local-name is not 
defined.
 [LARGEISH]
   write(*,*) XYZ, I, LARGEISH(INT(1,SELECTED_INT_KIND(18)))
----------------------^
implicit_mod.f90(8) : Error: Name in only-list does not exist.   [I]
   use implicit_mod, only: XYZ => ABC, I, LARGEISH => HUGE
---------------------------------------^
compilation aborted for implicit_mod.f90 (code 1)

C:\gfortran\clf\implicit_mod>gfortran implicit_mod.f90
implicit_mod.f90:3.21:

   implicit real(len(ABC)) (B)
                     1
Error: Parameter 'abc' at (1) has not been declared or is a variable, which 
does
 not reduce to a constant expression
implicit_mod.f90:8.7:

   use implicit_mod, only: XYZ => ABC, I, LARGEISH => HUGE
       1
Fatal Error: Can't open module file 'implicit_mod.mod' for reading at (1): 
No su
ch file or directory

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> I've found what I think is a bug in (not the newest version of) Fortran
> on VMS ALPHA.  Anyone else using this?
> 
> Here is a minimal example:
> 
> MODULE BLA
> INTEGER :: I=HUGE(1)
> END MODULE BLA
> PROGRAM TEST
> USE BLA, ONLY: I, HUGE
> PRINT*, I
> END PROGRAM TEST
> 
> In other words, if one adds to the ONLY list in the USE statement the
> name of an intrinsic function which is used in the corresponding module,
> then no error or warning is given.  However, if the intrinsic function
> is not used in the module, or if one just has some other name, then an
> error is generated.
> 
> However, one does get an error if one tries to use the name of the 
> intrinsic function as a variable name.  So, the bug looks harmless, but
> appears to be a bug nevertheless.

I'm not sure I understand what it is that you think is in error. Your
description sounds like what I'd expect. Namely

1. If the intrinsic function is referenced in the specification part of
the module, then it would be a name known in that module, and thus
available for access via USE. Having an appropriate INTRINSIC statement
(or a type declaration statement with the intrinsic attribute) should
have simillar effects in terms of making the name available for export
via USE of the module. You should be able to specify that intrinsic name
in a USE of the module without error. That sounds like what you said
happens.

2. If nothing in the specification part of the module makes the
intrinsic name known in the module, then trying to specify the intrinsic
nam ein a USE of the module should generate an error. That also sounds
like what you said happens.

Maybe I misunderstood what you said was happening. But I sure don't see
an error based on your description. If you still think there is an error
there, then I suggest you post exactly the code that you think triggers
a compiler bug. You posted one code above, but I can't tell from your
description whether you think the compilers behavior on that particular
version is wrong or whether you think that was ok, but the behavior of
some modified version was wrong. Since everything you described sounds
to me like the compiler got it right, I can't tel which version you
think is wrong.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

"Richard Maine" <nospam@see.signature> wrote in message 
news:1ko0r4w.1l4oy6y4ckf34N%nospam@see.signature...

> 1. If the intrinsic function is referenced in the specification part of
> the module, then it would be a name known in that module, and thus
> available for access via USE. Having an appropriate INTRINSIC statement
> (or a type declaration statement with the intrinsic attribute) should
> have simillar effects in terms of making the name available for export
> via USE of the module. You should be able to specify that intrinsic name
> in a USE of the module without error. That sounds like what you said
> happens.

Well then, what about:

C:\gfortran\clf\implicit_mod>type type.f90
module typenames
   implicit character(size([type(integer)::1,2,3])) (A-B)
end module typenames

program main
   use typenames, only: natural => integer
   type(natural) x

   x = 42
   write(*,*) x
end program main

C:\gfortran\clf\implicit_mod>gfortran type.f90 -otype
type.f90:6.23:

   use typenames, only: natural => integer
                       1
Error: Symbol 'integer' referenced at (1) not found in module 'typenames'
type.f90:7.16:

   type(natural) x
                1
Error: Derived type 'natural' at (1) is being used before it is defined

Here, type(integer) is referenced in the specification part of the
module, but it doesn't seem to be available for access via USE.
I would like very much for this to work :)

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 2012-07-30 1:39 PM, James Van Buskirk wrote:
> "Richard Maine" <nospam@see.signature> wrote in message
> news:1ko0r4w.1l4oy6y4ckf34N%nospam@see.signature...
>
>> 1. If the intrinsic function is referenced in the specification part of
>> the module, then it would be a name known in that module, and thus
>> available for access via USE. Having an appropriate INTRINSIC statement
>> (or a type declaration statement with the intrinsic attribute) should
>> have simillar effects in terms of making the name available for export
>> via USE of the module. You should be able to specify that intrinsic name
>> in a USE of the module without error. That sounds like what you said
>> happens.
>
> Well then, what about:
>
> C:\gfortran\clf\implicit_mod>type type.f90
> module typenames
>     implicit character(size([type(integer)::1,2,3])) (A-B)
 > end module typenames

As an aside, the thing at the front of an array constructor is a 
/type-spec/, not a /declaration-type-spec/ - the compiler should have 
flagged a syntax error here.  I think that's already been reported.

FWIW ifort 12.1.5 rolls up into a ball and makes small giggling noises 
when it sees the corrected code:

2012-07-30 intrinsic integer.f90(2): error #5082: Syntax error, found 
'(' when expecting one of: (
    implicit character(size([integer::1,2,3])) (A-B)
----------------------------------------------^

i.e. It found what it was expecting...

This "feature" of a reference to an intrinsic being enough to make it 
into the list of entities that a module "exports" strikes me as a bit 
bizarre.

"Ian Harvey" <ian_harvey@bigpond.com> wrote in message 
news:2boRr.1136$qv3.264@viwinnwfe01.internal.bigpond.com...

> As an aside, the thing at the front of an array constructor is a 
> /type-spec/, not a /declaration-type-spec/ - the compiler should have 
> flagged a syntax error here.  I think that's already been reported.

Thanks for informing me about that distinction.  So I should have
written:

C:\gfortran\clf\implicit_mod>type type1.f90
module typenames
   implicit type(integer) (A-B)
end module typenames

program main
   use typenames, only: natural => integer
   type(natural) x

   x = 42
   write(*,*) x
end program main

C:\gfortran\clf\implicit_mod>gfortran type1.f90 -otype1
type1.f90:6.23:

   use typenames, only: natural => integer
                       1
Error: Symbol 'integer' referenced at (1) not found in module 'typenames'
type1.f90:7.16:

   type(natural) x
                1
Error: Derived type 'natural' at (1) is being used before it is defined

> 2012-07-30 intrinsic integer.f90(2): error #5082: Syntax error, found '(' 
> when expecting one of: (
>    implicit character(size([integer::1,2,3])) (A-B)
> ----------------------------------------------^

> i.e. It found what it was expecting...

Well, no one expects the Spanish Inquisition.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 2012-07-30 3:25 PM, James Van Buskirk wrote:
> "Ian Harvey" <ian_harvey@bigpond.com> wrote in message
> news:2boRr.1136$qv3.264@viwinnwfe01.internal.bigpond.com...
>
>> As an aside, the thing at the front of an array constructor is a
>> /type-spec/, not a /declaration-type-spec/ - the compiler should have
>> flagged a syntax error here.  I think that's already been reported.
>
> Thanks for informing me about that distinction.  So I should have
> written:
>
> C:\gfortran\clf\implicit_mod>type type1.f90
> module typenames
>     implicit type(integer) (A-B)
> end module typenames
>
> program main
>     use typenames, only: natural => integer
>     type(natural) x
>
>     x = 42
>     write(*,*) x
> end program main
>
> C:\gfortran\clf\implicit_mod>gfortran type1.f90 -otype1
> type1.f90:6.23:
>
>     use typenames, only: natural => integer
>                         1
> Error: Symbol 'integer' referenced at (1) not found in module 'typenames'
> type1.f90:7.16:
>
>     type(natural) x
>                  1
> Error: Derived type 'natural' at (1) is being used before it is defined

This is messing with my head.  I need wine.

Syntax rule R403 is what allows TYPE ( /intrinsic-type-spec/ ) and TYPE 
( /derived-type-spec/ ).  The /intrinsic-type-spec/ rule is then written 
using the keywords that you would expect.  The /derived-type-spec/ path 
says the thing inside the type (the /type-name/ ) must be an accessible 
*derived type*.

Does that mean that your 'natural' is an identifier that you can't 
syntactically use - you can rename the intrinsic type but not then do 
anything with it?

Ian Harvey <ian_harvey@bigpond.com> wrote:

(snip)

> This "feature" of a reference to an intrinsic being enough to make it 
> into the list of entities that a module "exports" strikes me as a bit 
> bizarre.

I suppose so, but if you consider the rest of the discussion,
when a name is a variable, when it is an intrinsic function,
and when an external function, then maybe not so strange.

Now, you could require that distinction to be explicit when
INTRINSIC NONE was in effect. All intrinsic functions declared
in INTRINSIC statements, and all external functions either
in EXTERNAL or with INTERFACE. That would make it completely
obvious that each name was declared, and much more work
for programmers. (And lose back compatibility.)

-- glen

In article <1ko0r4w.1l4oy6y4ckf34N%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> Maybe I misunderstood what you said was happening. But I sure don't see
> an error based on your description. If you still think there is an error
> there, then I suggest you post exactly the code that you think triggers
> a compiler bug. You posted one code above, but I can't tell from your
> description whether you think the compilers behavior on that particular
> version is wrong or whether you think that was ok, but the behavior of
> some modified version was wrong. Since everything you described sounds
> to me like the compiler got it right, I can't tel which version you
> think is wrong.

This code does NOT produce any error:

MODULE BLA
IMPLICIT NONE
INTEGER :: I=RADIX(1)
END MODULE BLA
PROGRAM TEST
USE BLA, ONLY: I, RADIX
IMPLICIT NONE
PRINT*, I
END PROGRAM TEST

My (naive?) expectation was that USE should be able to access objects 
DEFINED in the module.  RADIX is an intrinsic, available to both BLA and 
TEST.  Why does using it in BLA make it OK to USE it in TEST?

My compiler seems to behave the same as some others, so perhaps it is 
not a bug.  However, it still seems illogical to me.

In article <2boRr.1136$qv3.264@viwinnwfe01.internal.bigpond.com>, Ian
Harvey <ian_harvey@bigpond.com> writes: 

> This "feature" of a reference to an intrinsic being enough to make it 
> into the list of entities that a module "exports" strikes me as a bit 
> bizarre.

My point exactly.

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <2boRr.1136$qv3.264@viwinnwfe01.internal.bigpond.com>, Ian
> Harvey <ian_harvey@bigpond.com> writes: 
> 
> > This "feature" of a reference to an intrinsic being enough to make it
> > into the list of entities that a module "exports" strikes me as a bit
> > bizarre.
> 
> My point exactly.

I'm not sure why it is any different from an implicit variable
declaration being sufficient for the same thing. Or for that matter, an
external function reference... though I'm not sure one can swing one of
those in the right scope. The default accessibility is public, which
means that anything known in the module scope is accessible. The
intrinsic function name is known, therefore by default it is accessible.
Q.E.D. If you don't want it accessible, then declare it private. That's
what private is for.

Now I'd agree that it is unfortunate that there is nothing like implicit
none that also forces you to explicitly declare what external or
intrinsic procedures you use. Implicit none will catch external
functions, but not external subroutines; and it won't catch intrinsics.
But that has litle to do directly with module accessibility. That has
more to do with being able to use the things at all, module or no.

On the messier bit about the type name integer. I don't have time to
track that down right now (and I'm suspicious some f2008 featues might
be involved). But be aware that intrinsic type names are very special in
the language. They are as close as the language comes to reserved words.
They aren't reserved in all contexts. You can (but should not) have a
variable named integer. But you cannot have a derived type named
integer.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

In comp.lang.fortran Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:

(snip)

> My (naive?) expectation was that USE should be able to access objects 
> DEFINED in the module.  RADIX is an intrinsic, available to both BLA and 
> TEST.  Why does using it in BLA make it OK to USE it in TEST?

OK, how about this one that shows that you can actually 
reference intrinsics declared in a module.

(To me, declared, instead of defined, seems closer to right.)

MODULE BLA
IMPLICIT NONE
INTEGER :: I=RADIX(1)
END MODULE BLA
PROGRAM TEST
USE BLA, ONLY: I, THIS=>RADIX
IMPLICIT NONE
PRINT*, I, THIS(2)
END PROGRAM TEST

> My compiler seems to behave the same as some others, so perhaps it is 
> not a bug.  However, it still seems illogical to me.

-- glen

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <1ko0r4w.1l4oy6y4ckf34N%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes: 
> 
> > Maybe I misunderstood what you said was happening. But I sure don't see
> > an error based on your description. If you still think there is an error
> > there, then I suggest you post exactly the code that you think triggers
> > a compiler bug. You posted one code above, but I can't tell from your
> > description whether you think the compilers behavior on that particular
> > version is wrong or whether you think that was ok, but the behavior of
> > some modified version was wrong. Since everything you described sounds
> > to me like the compiler got it right, I can't tel which version you
> > think is wrong.
> 
> This code does NOT produce any error:
> 
> MODULE BLA
> IMPLICIT NONE
> INTEGER :: I=RADIX(1)
> END MODULE BLA
> PROGRAM TEST
> USE BLA, ONLY: I, RADIX
> IMPLICIT NONE
> PRINT*, I
> END PROGRAM TEST
> 
> My (naive?) expectation was that USE should be able to access objects
> DEFINED in the module.  RADIX is an intrinsic, available to both BLA and
> TEST.  Why does using it in BLA make it OK to USE it in TEST?
> 
> My compiler seems to behave the same as some others, so perhaps it is
> not a bug.  However, it still seems illogical to me.

Ok, well your expectation was just wrong, then. No, it has nothing to do
with being defined in the module.  For another example

   module mod1
        integer :: something
   end module mod1

    module mod2
       use mod1
    end module mod2

Makes "somthing" accessible from mod2. It was not defined in mod2; it is
just known there.  For another example

    module mod3
       interface
           function my_func(x)
              real, intent(in) :: x
              real :: my_func
           end function my_func
       end interface
    end module mod3

makes the external function my_func accessible from mod3 and also gives
in an explicit interface.  My_func was not defined in mod3. This one is
very common as a way of giving explicit interfaces for external
procedures.

Anyway, no, there is no notion of something having to be defined in a
module to be accesible from the module.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

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

> In comp.lang.fortran Phillip Helbig---undress to reply
<helbig@astro.multiclothesvax.de> wrote:

> > My (naive?) expectation was that USE should be able to access objects
> > DEFINED in the module.  RADIX is an intrinsic, available to both BLA and
> > TEST.  Why does using it in BLA make it OK to USE it in TEST?
> 
> OK, how about this one that shows that you can actually 
> reference intrinsics declared in a module.
> 
> (To me, declared, instead of defined, seems closer to right.)

I'd agree that declared is right.... but with the caveat that the
declaration can be implicit (as declarations can be). But that's not too
different from my (very informally worded) "known" in the module.
Because anything that is known has a declaration; if it doesn't have an
explicit declaration, then it has an implicit one.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

In article <1ko2ec8.kjmk3u1ur0cjkN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> > > This "feature" of a reference to an intrinsic being enough to make it
> > > into the list of entities that a module "exports" strikes me as a bit
> > > bizarre.
> > 
> > My point exactly.
> 
> I'm not sure why it is any different from an implicit variable
> declaration being sufficient for the same thing. Or for that matter, an
> external function reference... though I'm not sure one can swing one of
> those in the right scope. The default accessibility is public, which
> means that anything known in the module scope is accessible. 

OK, but in that case, why does the object have to be mentioned in the 
module in order to make it accessible to something which USEs the 
module?

> The
> intrinsic function name is known, therefore by default it is accessible.
> Q.E.D. If you don't want it accessible, then declare it private. That's
> what private is for.

Let me rephrase my question: Rather than asking why the mentioned 
intrinsic is available, perhaps I should ask why all the non-mentioned 
ones are not available.  If the rule is, it is available if it is known 
to the module then, since all intrinsics are known, it should be 
available.  (Whether using an intrinsic in this form makes any sense is 
another question, of course.)

In article <1ko2ewq.1hpnbe27zpo5cN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> Anyway, no, there is no notion of something having to be defined in a
> module to be accesible from the module.

OK, then why aren't all the other intrinsics available?  I DO get an 
error if the intrinsic is not mentioned in the module.

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <1ko2ewq.1hpnbe27zpo5cN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes: 
> 
> > Anyway, no, there is no notion of something having to be defined in a
> > module to be accesible from the module.
> 
> OK, then why aren't all the other intrinsics available?  I DO get an 
> error if the intrinsic is not mentioned in the module.

Well, other than just resorting to "because that's what the standard
says", which might well be where we are headed here, I'll note that the
other intrinsic names are not established in the module to be intrinsic
names. I'll not try to drag out the standard-speak, but that's what it
amounts to.

The other intrinsic names could also be used for other purposes.
Remember that they are not reserved. They could be variable names, for
example. Until you do something to establish that they are to be
considered as intrinsic names in the right scope, then they are not
"known" in that scope. Or perhaps to borrow Glen's suggestion, I could
say that they are not declared in the scope, either explicitly or
implicitly. If you reference the intrinsic, that amounts to an implicit
declaration of it. But if you don't have an explicit declaration of the
intrinsic, and you also don't have a reference to it, then there is no
declaration at all. That's sort of the sam ething as my saying that it
isn't "known" in the scope, but perhaps the formal terminology might sit
better with you than my informal and sloppy use of "known".

If that's not enough for you, I'm afraid I'll have to fall back on the
first point above. I've already spent to much time on this for a
vacation night in Barceloona (which is where I am at the moment).

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

Richard Maine <nospam@see.signature> wrote:

(snip)

> On the messier bit about the type name integer. I don't have time to
> track that down right now (and I'm suspicious some f2008 featues might
> be involved). But be aware that intrinsic type names are very special in
> the language. They are as close as the language comes to reserved words.
> They aren't reserved in all contexts. You can (but should not) have a
> variable named integer. But you cannot have a derived type named
> integer.

Is there a connection between INTEGER, TYPE(INTEGER) and 
CLASS(INTEGER)?

Specifically, I was trying to figure out in the previous
question about reallocating polymorphic arrays, if intrinsic
types should be allowed?

Not that it is at all applicable, but in Java the intrinsic
types are not objects, but arrays are objects. I have had programs
with arrays dimensioned [1] so that I could reference them as Object.

So, back to Fortran, can an unlimited polymorphic type reference
(I an not sure of the Fortran name) an INTEGER array, or only
a CLASS(someclass) array?

And, if it can, what do you put into the SAME_TYPE_AS
to compare against an intrinsic type?

-- glen

In article <1ko2hcd.g08tubr1prx2N%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> The other intrinsic names could also be used for other purposes.
> Remember that they are not reserved. They could be variable names, for
> example. Until you do something to establish that they are to be
> considered as intrinsic names in the right scope, then they are not
> "known" in that scope. Or perhaps to borrow Glen's suggestion, I could
> say that they are not declared in the scope, either explicitly or
> implicitly. If you reference the intrinsic, that amounts to an implicit
> declaration of it. But if you don't have an explicit declaration of the
> intrinsic, and you also don't have a reference to it, then there is no
> declaration at all. 

OK, this makes sense---and thus there is not a bug in my compiler here.

Whether or not this feature is useful, of course, is another issue.  One 
I can think of: Suppose one has a code with many function references, 
written before an intrinsic function of the same name was introduced.  
If one doesn't want to change the code, but does want to make the new 
intrinsic available, then one could USE it from a module which 
referenced it and use => to rename it.  :-)

> I've already spent to much time on this for a
> vacation night in Barceloona (which is where I am at the moment).

The wonders of the internet!

In comp.lang.fortran Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
> In article <1ko2ewq.1hpnbe27zpo5cN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes: 

>> Anyway, no, there is no notion of something having to be defined in a
>> module to be accesible from the module.

> OK, then why aren't all the other intrinsics available?  I DO get an 
> error if the intrinsic is not mentioned in the module.

That is why I said defined, and Richard reminded me that it
should be implicitly defined. All the intrinsics are "known"
to the compiler, such that they can be implicitly defined.

They aren't implicitly defined until they are used in the
appropriate context. 

(Not that I would have thought about this before, though.)

-- glen

On 2012-07-31 6:49 AM, glen herrmannsfeldt wrote:
> So, back to Fortran, can an unlimited polymorphic type reference
> (I an not sure of the Fortran name) an INTEGER array, or only
> a CLASS(someclass) array?

An unlimited polymorphic variable (that is an array) can "reference" an 
INTEGER array.

>
> And, if it can, what do you put into the SAME_TYPE_AS
> to compare against an intrinsic type?

You pass an object of the intrinsic type that you wish to compare against.

In contexts where a /type-spec/ is required (SELECT TYPE, for example) 
you use the keyword for the intrinsic type.

   CLASS(*), ALLOCATABLE :: thing(:)
   ALLOCATE(INTEGER :: thing(5))
   SELECT TYPE (thing)
   TYPE IS (INTEGER)
     thing = [1,2,3,4,5]
   END SELECT

CLASS IS (INTEGER) is not legal, as INTEGER is not a derived type name. 
  Besides which, INTEGER's have no class, having never learnt their 
manners as youngsters.

Ian Harvey <ian_harvey@bigpond.com> wrote:


(snip, I wrote)
>> So, back to Fortran, can an unlimited polymorphic type reference
>> (I an not sure of the Fortran name) an INTEGER array, or only
>> a CLASS(someclass) array?

> An unlimited polymorphic variable (that is an array) can 
> "reference" an INTEGER array.

>> And, if it can, what do you put into the SAME_TYPE_AS
>> to compare against an intrinsic type?

> You pass an object of the intrinsic type that you wish to 
> compare against.

Hmm, there should be an easy way to generate one of the 
appropriate type.

> In contexts where a /type-spec/ is required (SELECT TYPE, for example) 
> you use the keyword for the intrinsic type.

I didn't know about SELECT TYPE before. In Java, you have to do
it with if statements and the instanceof operator.

>   CLASS(*), ALLOCATABLE :: thing(:)
>   ALLOCATE(INTEGER :: thing(5))
>   SELECT TYPE (thing)
>   TYPE IS (INTEGER)
>     thing = [1,2,3,4,5]
>   END SELECT

-- glen

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> Whether or not this feature is useful, of course, is another issue.  One
> I can think of: Suppose one has a code with many function references,
> written before an intrinsic function of the same name was introduced.
> If one doesn't want to change the code, but does want to make the new
> intrinsic available, then one could USE it from a module which 
> referenced it and use => to rename it.  :-)

I've seen that one before. I was moderately surprised, the first time it
occurred to me, to find out that it actually worked. I don't think I've
used it for that purpose in real code; I've changed the user function
name instead. The cases where changing the user function name wasn't
viable for me turned out to be in f77, where this wasn't an option
anyway. But I was still curious to find if it would actually work. It
does (though I think there might have been a related bug in one
compiler).

And note that the module doesn't have to actually reference the
intrinsic. An explicit declaration of the intrinsic will also do and
seems more appropriate than adding some superfluous reference just for
the purpose of causing an implicit declaration. (You might be meaning an
informal definition of "reference" rather than the definition used in
the Fortran standard. A function is only technically referenced when you
do somehing that needs its value - that is you invoke it. Something like

   intrinsic sum

is not a reference, but will achieve the purpose fine).

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

Richard Maine <nospam@see.signature> wrote:

> Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
> wrote:
> 
> > OK, then why aren't all the other intrinsics available?  I DO get an
> > error if the intrinsic is not mentioned in the module.
> 
> ..other intrinsic names are not established in the module to be intrinsic
> names. I'll not try to drag out the standard-speak, but that's what it
> amounts to.
> 
> The other intrinsic names could also be used for other purposes.
> Remember that they are not reserved. They could be variable names, for
> example. Until you do something to establish that they are to be
> considered as intrinsic names in the right scope, then they are not
> "known" in that scope. Or perhaps to borrow Glen's suggestion, I could
> say that they are not declared in the scope, either explicitly or
> implicitly. If you reference the intrinsic, that amounts to an implicit
> declaration of it. But if you don't have an explicit declaration of the
> intrinsic, and you also don't have a reference to it, then there is no
> declaration at all.

A simple example illustrating this occurred to me sometime later. I
don't have a compiler handy on this laptop to check, but if you do

   module my_mod
      public real !--- Or choose any other intrinsic name that you like.
   end module my_mod

then the thing named REAL that is exported from this module is not the
intrinsic function. Nothing having declared, either explicitly or
implicitly, that a function is involved, what you have instead is an
implicitly declared scalar variable named "real" (and its type happens
to be real by the usual implicit rules).

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

On 7/31/12 2:13 PM, Richard Maine wrote:
> Richard Maine<nospam@see.signature>  wrote:
>
>> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>
>> wrote:
>>
>>> OK, then why aren't all the other intrinsics available?  I DO get an
>>> error if the intrinsic is not mentioned in the module.
>>
>> ..other intrinsic names are not established in the module to be intrinsic
>> names. I'll not try to drag out the standard-speak, but that's what it
>> amounts to.
>>
>> The other intrinsic names could also be used for other purposes.
>> Remember that they are not reserved. They could be variable names, for
>> example. Until you do something to establish that they are to be
>> considered as intrinsic names in the right scope, then they are not
>> "known" in that scope. Or perhaps to borrow Glen's suggestion, I could
>> say that they are not declared in the scope, either explicitly or
>> implicitly. If you reference the intrinsic, that amounts to an implicit
>> declaration of it. But if you don't have an explicit declaration of the
>> intrinsic, and you also don't have a reference to it, then there is no
>> declaration at all.
>
> A simple example illustrating this occurred to me sometime later. I
> don't have a compiler handy on this laptop to check, but if you do
>
>     module my_mod
>        public real !--- Or choose any other intrinsic name that you like.
>     end module my_mod
>
> then the thing named REAL that is exported from this module is not the
> intrinsic function. Nothing having declared, either explicitly or
> implicitly, that a function is involved, what you have instead is an
> implicitly declared scalar variable named "real" (and its type happens
> to be real by the usual implicit rules).
>

Just to muddy the waters, I'm sure there was an interpretation request 
several years ago about something like the following.

       module my_mod
          real  ::  A(10) = (/ (3.14, I=1,10) /)
       end module my_mod

Is "I" accessible or not was the question.  My recollection is "NO", the 
"I" thing can't be referenced in a USE of the module.  I don't recall 
the reasoning, other than it wasn't trivial.

Dick Hendrickson

Dick Hendrickson <dick.hendrickson@att.net> wrote:

(snip)

> Just to muddy the waters, I'm sure there was an interpretation request 
> several years ago about something like the following.

>       module my_mod
>          real  ::  A(10) = (/ (3.14, I=1,10) /)
>       end module my_mod

> Is "I" accessible or not was the question.  My recollection is "NO", the 
> "I" thing can't be referenced in a USE of the module.  I don't recall 
> the reasoning, other than it wasn't trivial.

It likely isn't trivial in standard-speak, but mostly the variable
only needs to exist at compile time.

Now, implied-DO for I/O statements may or may not generate
an actual loop in the object program.

-- glen

Dick Hendrickson <dick.hendrickson@att.net> wrote:

> Just to muddy the waters, I'm sure there was an interpretation request
> several years ago about something like the following.
> 
>        module my_mod
>           real  ::  A(10) = (/ (3.14, I=1,10) /)
>        end module my_mod
> 
> Is "I" accessible or not was the question.  My recollection is "NO", the
> "I" thing can't be referenced in a USE of the module.  I don't recall
> the reasoning, other than it wasn't trivial.

Yeah. I vaguely recall that interp request as well. I don't recall the
reasoning, or even the answer, but I think I can reconstruct a guess as
to what it might have been. I'm not confident my guess is right, but...

I think that the index variable in an array constuctor has scope only of
the constructor. Thus it isn't mentioned (or otherwise declared) in the
scope of the module.

Part of the reason that the index variable "has" to have scope only of
the constructor (other than just because that's what the standard says)
is that array constructors aren't necessarily evaluated during
execution. Some of them (including that example) can be evaluated at
compile time. Anyway, because you don't necessarily know when the array
constructor is evaluated, you don't know when the value of the index
variable migt be changed. I suppose that's not an issue for modules,
which don't have an execution sequence, but it can be a problem for
array constructors elsewhere. A way around having to figure out when the
value of the index variable is changed is to define the problem away by
essentially saying "never". The index variable does not have the same
scope as any variable of the same name that might exist in the scope of
the procedure (or module, or whatever); so there is never any effect to
worry about.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

On 2012-08-01 7:17 AM, Richard Maine wrote:
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>> Just to muddy the waters, I'm sure there was an interpretation request
>> several years ago about something like the following.
>>
>>         module my_mod
>>            real  ::  A(10) = (/ (3.14, I=1,10) /)
>>         end module my_mod
>>
>> Is "I" accessible or not was the question.  My recollection is "NO", the
>> "I" thing can't be referenced in a USE of the module.  I don't recall
>> the reasoning, other than it wasn't trivial.
>
> Yeah. I vaguely recall that interp request as well. I don't recall the
> reasoning, or even the answer, but I think I can reconstruct a guess as
> to what it might have been. I'm not confident my guess is right, but...
>
> I think that the index variable in an array constuctor has scope only of
> the constructor. Thus it isn't mentioned (or otherwise declared) in the
> scope of the module.
>
> Part of the reason that the index variable "has" to have scope only of
> the constructor (other than just because that's what the standard says)
> is that array constructors aren't necessarily evaluated during
> execution. Some of them (including that example) can be evaluated at
> compile time. Anyway, because you don't necessarily know when the array
> constructor is evaluated, you don't know when the value of the index
> variable migt be changed. I suppose that's not an issue for modules,
> which don't have an execution sequence, but it can be a problem for
> array constructors elsewhere. A way around having to figure out when the
> value of the index variable is changed is to define the problem away by
> essentially saying "never". The index variable does not have the same
> scope as any variable of the same name that might exist in the scope of
> the procedure (or module, or whatever); so there is never any effect to
> worry about.

A wrinkle in the language is that while that "I" might only have the 
scope of the implied do, you can't explicitly declare it in that scope - 
if IMPLICIT NONE is in effect you have to create an "I" in the parent 
scope, even though you may never use it.  In the case of the 
specification part of a module, you then may need to "un-public" that 
pointless "I".

A similar situation existed for the index variables in FORALL until 
F2008, when the ability to declare the index variable just in the scope 
of the FORALL was added.  It would be nice for this capability to 
declare-the-thing-in-the-scope-where-it-is-used was added for implied 
dos too.  Syntactically it shouldn't be too hard to permit a type spec 
in at the front of the ac-implied-do-control.

(I recall having compilers whinge about the parent declaration of an 
index variables in an implied-do or FORALL never being used.)

Ian Harvey <ian_harvey@bigpond.com> wrote:

> On 2012-08-01 7:17 AM, Richard Maine wrote:
> > Dick Hendrickson <dick.hendrickson@att.net> wrote:
> >

> >>         module my_mod
> >>            real  ::  A(10) = (/ (3.14, I=1,10) /)
> >>         end module my_mod
> >>
> >> Is "I" accessible or not was the question.
> >
> > I think that the index variable in an array constuctor has scope only of
> > the constructor. Thus it isn't mentioned (or otherwise declared) in the
> > scope of the module.

> A wrinkle in the language is that while that "I" might only have the 
> scope of the implied do, you can't explicitly declare it in that scope -
> if IMPLICIT NONE is in effect you have to create an "I" in the parent
> scope, even though you may never use it.  In the case of the 
> specification part of a module, you then may need to "un-public" that
> pointless "I".

Yes. The whole thing about having to declare the type in the "wrong"
scope is a bit of a pet peeve of mine. That's one of the several reasons
I dislike statement functions, for example. It is also why I
deliberately avoid using something quite as simple and common as "I" for
the index variable name of my array constructors in contexts like that.
If I do something like accidentally forget my usual global private
statement, I would not want a public "I" to slip out; too many
conflicts. So I usually use a name like i_do.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle

On 7/31/12 4:11 PM, glen herrmannsfeldt wrote:
> Dick Hendrickson<dick.hendrickson@att.net>  wrote:
>
> (snip)
>
>> Just to muddy the waters, I'm sure there was an interpretation request
>> several years ago about something like the following.
>
>>        module my_mod
>>           real  ::  A(10) = (/ (3.14, I=1,10) /)
>>        end module my_mod
>
>> Is "I" accessible or not was the question.  My recollection is "NO", the
>> "I" thing can't be referenced in a USE of the module.  I don't recall
>> the reasoning, other than it wasn't trivial.
>
> It likely isn't trivial in standard-speak, but mostly the variable
> only needs to exist at compile time.
>
> Now, implied-DO for I/O statements may or may not generate
> an actual loop in the object program.
>
> -- glen
I think Richard was on the right track (at least, that's the way to 
bet).  Chapter 16 talks about statement entities, like my "I" above, and 
those only have the scope of the statement.  I think that means the I 
isn't visible anywhere outside of the statement and not USEable from 
outside the module.

The implied-DO index in an I/O statement isn't a statement entity.  It's 
just a plain old variable without any specific magic due to I/O. 
Whether or not code is generated doesn't matter; variables get 
attributes from their declarations and specifications (which might be 
implicit), not from whether they are used at run time.

Dick Hendrickson

Phillip Helbig wrote:
> This is Compaq Fortran V7.5-2630-48C8L.  What is the latest version for
> ALPHA?  For Itanium?  Will any standard later than F95 ever be
> supported?

The GNU Compiler Collection (GCC) supports VMS on Alpha and also 
ia64-hp-openvms. This includes gfortran. However, you probably have to 
compile GCC yourself. You need the current GCC 4.8 as it contains some 
fixes for VMS (done in April/May this year).

gfortran supports several Fortran 2003 and Fortran 2008 features, but 
unfortunately not yet all of them.*

See "Building from Source" at http://gcc.gnu.org/wiki/GFortranBinaries

Tobias

* For an overview about the supported F2003/F2008/TS29113 features, see 
http://gcc.gnu.org/wiki/Fortran2003Status , 
http://gcc.gnu.org/wiki/Fortran2008Status , 
http://gcc.gnu.org/wiki/TS29113Status and 
http://gcc.gnu.org/wiki/GFortran#news

In article <501998BE.90502@net-b.de>, Tobias Burnus <burnus@net-b.de>
writes: 

> Phillip Helbig wrote:
> > This is Compaq Fortran V7.5-2630-48C8L.  What is the latest version for
> > ALPHA?  For Itanium?  Will any standard later than F95 ever be
> > supported?
> 
> The GNU Compiler Collection (GCC) supports VMS on Alpha and also 
> ia64-hp-openvms. This includes gfortran. However, you probably have to 
> compile GCC yourself. You need the current GCC 4.8 as it contains some 
> fixes for VMS (done in April/May this year).
> 
> gfortran supports several Fortran 2003 and Fortran 2008 features, but 
> unfortunately not yet all of them.*
> 
> See "Building from Source" at http://gcc.gnu.org/wiki/GFortranBinaries

Even if it doesn't support F2003 fully, it would be nice to have another 
compiler on the same machine, at least for comparison.  When I have 
time, I'll try to build it.