Intrinsic modules and compatibilty with older standards

[arjenmarkus]

Hi,

Fortran 2003 introduced the concept of intrinsic modules.
What I would like to know is what exactly is the difference
with an ordinary module. Here is the context:

For the PLplot project (http://plplot.sf.net) we use a bunch of
compiler-specific routines (iargc() for instance from gfortran).
I would like to get rid of them if the compiler in question
supports the Fortran 2003 equivalents. But I do need to make
sure that the previous solution works if the compiler happens
not to support (enough of) the Fortran 2003 standard.

So I wonder if I can simply use:

use iso_fortran_env

or
use ieee_arithmetic

instead of:

use, intrinsic :: iso_fortran_env|ieee_arithmetic

provided via our own code in case the compiler does not
have them. (I can use the machinery of "external" routines
to control whether the intrinsic versions are used or not)

Put more succinctly: is my assumption right that the intrinsic
keyword is only necessary to ensure that a haphazard user defined
module of the same is NOT used?

Regards,

Arjen

[Richard Maine]

arjenmarkus <arjen.m...@gmail.com> wrote:

> Fortran 2003 introduced the concept of intrinsic modules.
> What I would like to know is what exactly is the difference
> with an ordinary module.

Well, the biggest difference is that an ordinary module has to do things
that can be done in principle by "ordinary" Fortran. They don't have to
be actually written in Fortran, but they do have to look as though they
might be (that's my informal wording instead of specific words of the
standard).

An intrinsic module, on the other hand, can have effects on the compiler
that could not be implemented in Fortran source code. The two intrinsic
modules you mentioned don't do anything particularly wierd like that,
but IEEE_features does. IEEE_features is a bit.... strange.... in that
you never actually *DO* anything useful with the things that you access
from it. Their action depends only on whether or not they are accessed
instead of on then doing anything with the accessed things. They are
somewhat like compiler switches.

> Here is the context:
...

> Put more succinctly: is my assumption right that the intrinsic
> keyword is only necessary to ensure that a haphazard user defined
> module of the same is NOT used?

Yes. You never *HAVE* to specify the intrinsic keyword; it isn't what
makes a module intrinsic.

I find it a bit inconsistent that the default for intrinsic versus
non-intrinsic modules is the opposite of that for intrinsic versus
non-intrinsic procedures.

If there is both an intrinsic and a non-intrinsic procedure of the same
name, then lacking any intructions to the compiler about which one is
meant, you get the intrinsic one. (That only applies to non-intrinsic
external procedures because non-external ones always come with
"instructions to the compiler" of one form or other; namely, they are
either in the source code of the current scope or accessed via USE).

But if there is both an intrinsic and a non-intrinsic module of the same
name, then lacking any instructions to the compiler, you get the
non-intrinsic one.

There was probably a reason for this inconsistency. I was probably even
there when the reason was advanced, but I don't recall what it was (or
whether I agreed with it).

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

[Tobias Burnus]

On 11/02/2011 01:37 PM, arjenmarkus wrote:
> For the PLplot project (http://plplot.sf.net) we use a bunch of
> compiler-specific routines (iargc() for instance from gfortran).
> I would like to get rid of them if the compiler in question
> supports the Fortran 2003 equivalents.

I think Richard comprehensively answered the module question.

I want to jump on the "iargc" which you mentioned as example. In case
you do not know, it exists a package called f2kcli which provides the
Fortran 2003 command-line intrinsics to Fortran 77/90/95 compilers. See
http://www.winteracter.com/f2kcli/

Given that F2003 exists already quite long and given that it has been an
highly requested and simple feature, I wonder how many compilers are
still in use, which do not support it. (I don't think there are many,
but I am sure there are some.)


(Actually, I always wondered why Fortran 2003 and 2008 didn't add more
intrinsic procedures via intrinsic modules. Currently, nearly all* newly
added intrinsics "pollute" the name space and might clash with external
procedures. I think the ERF and GAMMA F2008 additions have the highest
potential to clash - and for GAMMA possibly even with a different meaning.)

Tobias

* There are intrinsic-module functions in the IEEE modules and in
ISO_C_BINDING.

[Richard Maine]

Tobias Burnus <bur...@net-b.de> wrote:

> On 11/02/2011 01:37 PM, arjenmarkus wrote:
> > For the PLplot project (http://plplot.sf.net) we use a bunch of
> > compiler-specific routines (iargc() for instance from gfortran).
> > I would like to get rid of them if the compiler in question
> > supports the Fortran 2003 equivalents.
>
> I think Richard comprehensively answered the module question.
>
> I want to jump on the "iargc" which you mentioned as example. In case
> you do not know, it exists a package called f2kcli which provides the
> Fortran 2003 command-line intrinsics to Fortran 77/90/95 compilers. See
> http://www.winteracter.com/f2kcli/

I skimmed that part of Arjen's posting pretty quickly, so I didn't much
notice the particular reference to iargc. I agree that f2kcli is an
excellent resource for that, and I've pointed people to it before.

> (Actually, I always wondered why Fortran 2003 and 2008 didn't add more
> intrinsic procedures via intrinsic modules. Currently, nearly all* newly
> added intrinsics "pollute" the name space and might clash with external
> procedures. I think the ERF and GAMMA F2008 additions have the highest
> potential to clash - and for GAMMA possibly even with a different meaning.)

I wondered the same... and I unsucessfully advocated an increased use of
the module approach, at least in f2003. I didn't find sufficient support
on the committee, though. And by f2008 I was no longer very much in the
loop.

[Ian Harvey]

On 11/03/2011 03:47 AM, Tobias Burnus wrote:

> (Actually, I always wondered why Fortran 2003 and 2008 didn't add more
> intrinsic procedures via intrinsic modules. Currently, nearly all* newly
> added intrinsics "pollute" the name space and might clash with external
> procedures. I think the ERF and GAMMA F2008 additions have the highest
> potential to clash - and for GAMMA possibly even with a different meaning.)

Here here! I'd go further - allow ALL the intrinsic procedures to be
explicitly brought in via intrinsic modules.

If intrinsic procedures were introduced via modules then there is the
facility for renaming them. Handy when those in years gone past decided
to name one of the big, omnipresent and fundamental arrays in the
program SUM, and us more modern miscreants occasionally want to tally up
a vector...

USE, INTRINSIC :: ... should also have required (implicitly or via a
constraint) the ONLY: clause, so future standards can go completely
feral about the identifiers that come bouncing into the scope with such
a module.

[Richard Maine]

Ian Harvey <ian_h...@bigpond.com> wrote:

> Here here! I'd go further - allow ALL the intrinsic procedures to be
> explicitly brought in via intrinsic modules.
>
> If intrinsic procedures were introduced via modules then there is the
> facility for renaming them. Handy when those in years gone past decided
> to name one of the big, omnipresent and fundamental arrays in the
> program SUM, and us more modern miscreants occasionally want to tally up
> a vector...

That capability exists now. The standard doesn't specify modules for the
intrinsic procedures, but the user can use ordinary (non-intrinsic)
modules to wrap the intrinsic procedures. Yes, that includes the
renaming facilities. Try, for example

module wrapped_intrinsics
intrinsic sum
end module wrapped_intrinsics
program sum_thing
use wrapped_intrinsics, summation => sum
integer :: sum(4) = [1,2,3,4]
write (*,*) summation(sum)
end program sum_thing

I just did so. Works with GFortran. I see that it fails with g95. Looks
like maybe g95 imports it by both the original name and the new one.
Haven't heard from Andy in an age, so I don't know that there's much
point in submitting a bug report.

I'm not disagreeing with you. I'd think it good for the standard to go
ahead and put them in intrinsic modules for you, though it would have to
also still make them available as intrinsic procedures for
compatibility; no reason you couldn't have both.

I'm just pointing out that you actually can do this now. I think I
recall mentioning the trick in committee at one point, as it was evident
to me that there were at least some on the committee who didn't realize
that the standard allowed it.

[Ian Harvey]

On 11/03/2011 11:11 AM, Richard Maine wrote:
..
> That capability exists now. The standard doesn't specify modules for the
> intrinsic procedures, but the user can use ordinary (non-intrinsic)
> modules to wrap the intrinsic procedures. Yes, that includes the
> renaming facilities. Try, for example
>
> module wrapped_intrinsics
> intrinsic sum
> end module wrapped_intrinsics
> program sum_thing
> use wrapped_intrinsics, summation => sum
> integer :: sum(4) = [1,2,3,4]
> write (*,*) summation(sum)
> end program sum_thing

Neat - I wasn't aware of that. Beyond things being used as actual
arguments, I had always disdainfully regarded the intrinsic statement as
just being a way of hacking in extensions.

(I'll admit to being a little disappointed this works - bringing
intrinsics in via modules just seems "neater" to me and this has removed
one of the more concrete arguments that I had in my head for justifying
that...)

[Richard Maine]

I quite understand your point. I also think using modules for the
purpose is much cleaner. Given the way that intrinsics keep getting
added willy-nilly outside of modules, it seems evident to me that my
perspective on this is not universally shared on the committee. But it
sounds like I share it at least with you (and some others as well).

[arjenmarkus]

Hi Richard, Tobias,

thanks for these explanations.

As for iargc() and consorts:
While many _current_ compilers, if not all, will support these parts
of F2003, unfortunately you can not assume that all people will use
recent versions. The fl2cli package is a worthwhile suggestion though -
I will see whether I can add that to the mix.

Regards,

Arjen

[arjenmarkus]

I like that feature.

Regards,

Arjen

[Wolfgang Kilian]

On 11/03/2011 02:40 AM, Richard Maine wrote:
> Ian Harvey<ian_h...@bigpond.com> wrote:
>
>> On 11/03/2011 11:11 AM, Richard Maine wrote:
>> ..

>>> [...]

>>
>> (I'll admit to being a little disappointed this works - bringing
>> intrinsics in via modules just seems "neater" to me and this has removed
>> one of the more concrete arguments that I had in my head for justifying
>> that...)
>
> I quite understand your point. I also think using modules for the
> purpose is much cleaner. Given the way that intrinsics keep getting
> added willy-nilly outside of modules, it seems evident to me that my
> perspective on this is not universally shared on the committee. But it
> sounds like I share it at least with you (and some others as well).
>

Seconded.

It appears as if stand-alone procedures (intrinsic or external) were
still the natural way of coding, and modules were something esoteric.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo