(j3.2006) other entities in standard modules

Whitlock, Stan stan.whitlock
Wed Jan 31 10:00:23 EST 2007


I agree that [359:28-29] means that processors can extend intrinsic
modules.  But I read [364:22-23] as saying the IEEE intrinsic modules
define these five derived types but I don't read it to prohibit a
processor from adding other public derived types to these intrinsic

I may be erring on the implementer's side, seeing no prohibition,
instead of on the language lawyer side, seeing no permission.


-----Original Message-----
From: j3-bounces at j3.scs.gmu.edu [mailto:j3-bounces at j3.scs.gmu.edu] On
Behalf Of Malcolm Cohen
Sent: Wednesday, January 31, 2007 4:29 AM
To: J3 Fortran Committee
Subject: Re: (j3.2006) other entities in standard modules

Hi folks,

Dick Hendrickson said:
> In Fortran 2003, chapter 15 (page 391:15) says "a processor may
> provide other public entities in the ISO_C_BINDING intrinsic
> But, I couldn't find find similar words in chapter 14 about the
> IEEE modules.

That's because the IEEE module stuff was written by gods and will never
ever need changing or extension, whereas ISO_C_BINDING and
were written by us mere mortals.  And 754R will not provide any more
functionality than 754.

> So, the obvious question.  May a processor provide other public
> in the various IEEE intrinsic modules?  If not, why not.  If so, why
> does chapter 15 need to say anything about other public entities.

Alternatively it's an obvious contradiction in c14 and should be fixed.
Our intent is clear from [359:28-29].  Seriously, the wording in c14 is
substantially at variance with the normal style and has all kinds of
misstatements e.g. at [364:22-23] where it implies that even if the
processor provides extra public entities they cannot be derived types.

Someone should rewrite this stuff in their copious spare time.

Preferably someone else!

........................Malcolm Cohen (malcolm at nag-j.co.jp), Nihon NAG,
J3 mailing list
J3 at j3.scs.gmu.edu

More information about the J3 mailing list