Fortran - Extensions as intrinsic modules?

Author

Extensions as intrinsic modules?

Joe Krahn

2006-04-20, 7:04 pm

Extensions are common in Fortran compilers because they can be useful,
but they can also cause a lot of problems. Instead of avoiding
extensions altogether, it would be nice to explicitly request/use
extensions. Is it within the standards to do this be done in the form of
an intrinsic module?

A good example is the extension to allow boolean operators as bitwise
operators when used with integer operands. These operators could easily
be defined in a module, which could be explicitly USEd in a few places
without the risk of masking bugs where you used an integer variable in a
logical expression by mistake.

However, many extensions cannot be encapsulated in a proper module,
because they include things like non-standard intrinsic types and
statement extensions. Is the concept of an intrinsic module in the F2003
(and newer in-progress) standards defined in such a way that it would
allow for importing language features that are outside the scope of a
normal non-intrinsic module?

In either case, do other people think something like this is a useful
way to formalize the use of extensions?

Joe

Richard E Maine

2006-04-20, 7:04 pm

Joe Krahn <lastname_at_niehs.nih.gov@x.y.z> wrote:

> Extensions are common in Fortran compilers because they can be useful,
> but they can also cause a lot of problems. Instead of avoiding
> extensions altogether, it would be nice to explicitly request/use
> extensions. Is it within the standards to do this be done in the form of
> an intrinsic module?

Well, 2 answers.

1. The simple answer. An extension is, by definition, something outside
the standard. It is therefore not covered by the standard. The Fortran
standard is deliberately permissive in allowing extensions. Thus a
compiler can do darn near anything it wants with an extension....
including what you are asking for here. There are very few limitations
relating to extensions. The most significant are

a) The compiler still has to handle standard-conforming code
correctly. If an "extension" causes standard-conforming code to be
interpreted other than as specified by the standard, then that's not an
extension; it is a conflict/violation. There are even a few exceptions
to that. For example, a compiler can have compiler-specific intrinsics,
which can cause standard-conforming code to be interpreted differently.
And, of course, a compiler can always have a switch to turn off
features, making the compiler standard-conforming with some switch
settings.

b) In some cases, the compiler has to be able to diagnose that an
extension is being used. That doesn't apply to all cases, and the
diagnostic doesn't have to be enabled by default.

Neither of those are very severe bars to extensions.

So, yes, a compiler can do that. A program that uses such a compiler
extension is a non-standard program, but that's pretty much true of all
extensions - a compiler can have them and still be standard-conforming,
but a proram that uses them isn't.

2. The slightly deeper answer. Answer 1 is the "formal" one. Not
"official" (I can't give official answers), but at least based on
strictly reading the standard. I'll reinforce that answer with a bit of
"arm-waving" analogy here, trying to show that not only is such a thing
allowed by the exact words of the standard, but even that it fits in the
"spirit". The "spirit" is, of course, a harder thing to pin down, but I
think we can do it well enough in this case.

The IEEE modules in F2003 do something that sounds very much like what
you are suggesting here. They do more than just make identifiers from
the modules accessible. Depending on what identifiers you USE from the
modules, the working of the compiler can change. You can't do this in a
user-written module, except as specifically provided for in the standard
(i.e. such things as defined operators). But intrinsic modules can have
pther effects beyond those doable with user-written modules. Intrinsic
functions provided some precedent for distinctions like this; there have
long been (and still are) intrinsic functions that did things that could
not be done with user-written functions.

The notion of using intrinsic modules in this way was pretty
controversial when it was introduced to the committee. But in the end,
it did pass and is in the F2003 standard. I claim that it establishes
that it is within the spirit of the standard to have an intrinsic module
whose USE changes how a scoping unit is compiled.

In summary. Both answers are "yes". Just slightly different takes on
getting there.

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

Sponsored Links