Len Makin, CSIRO Maths & Info Sci, Melbourne. wrote:
> Swietanowski Artur <[log in to unmask]> wrote:
> > What about adding compiler command line options for things like
> > - compulsory array bounds runtime checking,
> > - treating implicit none as the default (or, indeed, the only
> > allowed state),
> > - making PRIVATE the default in modules,
> The excellent Cray compiler, against which I measure all progress in
> Fortran,
Flattery will get you nowhere... but you don't have to stop. :^)
I *do* consider this high praise. It has been well over six
years since I taught in Melbourne, but I remember it well. It
was a CSIRO climate researcher who taught me the value of a 1%
speedup.
Alas, I only wish I could *really* take credit. I have nothing
to do with compiler development except as a bug reporter and
occasional gadfly, but I *do* know a number of folks who are and
have been involved.
I will pass the praise along.
> has options for all of these, EXCEPT implicit PRIVATE (Hint, hint
> Roger G...? )
Since SGI and Cray Fortran compiler development have more or less
merged now (well, at least they seem to be "reading from the same
script"), Richard Shapiro might be more of a direct ear than I,
but I will pass this suggestion along as well.
> I am fully in favour of the standards committee turning
> their attention to such compiler options, even with the many difficulties
> associated with varying OS environments.
It seems to me that if multiple options of behavior are truly
desired, the best way to standardize those options would be the
same way that it was done in Fortran 90. That is, define a new
source form (or similar concept) in which the desired options
are the default behavior. In this case, we could call it the
"safety" source form. "Safety form" might be defined as "free
form" with the following semantic differences for example:
- IMPLICIT NONE default
- PRIVATE default in modules
- bounds/conformance/argument checking required (?)
- explicit interface required for all calls (?)
- assumed-size (*) array arguments disallowed (?)
- COMMON disallowed (?) except in modules (?)
- Uninitialized and deallocated pointers implicitly
disassociated ("undefined" state disallowed) (?)
- Labels allowed only for FORMAT, END=, ERR=, and
EOR= (GOTO and labelled-DO disallowed) (?)
Those marked (?) are those that, IMO, seem to imply a truly
significant performance, functionality, or recoding impact.
Creating a new source form seems like a way of forcing optional
behavior into compilers without specifying compiler options in
the standard. I am not necessarily advocating a new source form
here. However, if the committee finds such optional behavior to
be important to Fortran, I would rather see a new "source form,"
or something similar, than see command-line options in the
standard.
"Safety form" seems cheap to implement compared to the original
cost of "free form." I doubt a compiler would need a third
parser to support "safety form," unlike the way the Fortran 90+
compilers which need a second parser to support "free form."
-------- Cray Research --------- Roger Glover
-- A Silicon Graphics Company -- http://home.cray.com/~glover
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|