(j3.2006) Intrinsic modules

[Bill Long]

Craig Dedo wrote:
> Van and Everyone Else:
> 	No, there is no way to tell a compiler to prefer intrinsic modules
> to nonintrinsic modules of the same names.  In fact, such behavior would
> directly contradict the normative text of the Fortran 2003 standard and the
> current draft.  

Which is why most vendors probably don't do this.  However, I think Van 
was explicitly asking if vendors provided a switch that intentionally 
makes their compilers non-conforming, and does the opposite of what the 
standard specifies.  There are lots of switches like that already - the 
infamous -r8 comes to mind.  The one Van is asking for is pretty 
obscure, and would be relevant for very few codes - maybe only one.   I 
would be interested to see if it occurred to any vendor to provide such 
a switch.  We don't.

Cheers,
Bill




The relevant text is in section 11.2.1 in Fortran 2003
> (03-007) [254:8-10] and section 11.2.2p3 in the current draft (09-007r3)
> [273:27-28].
> 
> [Begin quote]
> A use-stmt without a module-nature provides access either to an intrinsic or
> to a nonintrinsic module. If the module-name is the name of both an
> intrinsic and a nonintrinsic module, the nonintrinsic module is accessed.
> [End of quote]
> 
> 	Obviously, any change in this preference rule would create a
> backwards incompatibility with Fortran 2003.
> 
> 	I find this preference rule to be somewhat surprising.  I remember
> that when we discussed the IEEE intrinsic modules, I raised a question about
> a particular example in one of John Reid's drafts.  He had left out the ",
> INTRINSIC" module-nature in the example.  The answer I got was that it did
> not matter; as proposed, the compiler would pick the intrinsic module if the
> module-nature was left off the USE statement.
> 
> 	Does anyone remember why J3 chose to prefer nonintrinsic modules
> over intrinsic modules of the same name?
> 
> 	FWIW, if J3 decides to develop a way to state the opposite
> preference, then it should be done with explicit syntax at the procedure or
> module levels, immediately before the relevant USE statements.  This would
> be similar to IMPLCIT or IMPLICIT NONE statements overriding default
> implicit typing.
> 
> Sincerely,
> Craig T. Dedo
> 17130 W. Burleigh Place
> P. O. Box 423                  Mobile Phone:  (414) 412-5869
> Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
> USA
> Linked-In:  http://www.linkedin.com/in/craigdedo
> 
> 
> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf
> Of Van Snyder
> Sent: Friday, November 20, 2009 20:08
> To: j3
> Subject: (j3.2006) Intrinsic modules
> 
> For the compiler vendors:
> 
> Is there a way to tell your compiler to prefer intrinsic modules
> (hopefully a list of specific ones) to a nonintrinsic one of the same
> name where <module-nature> is not specified in a USE statement
> (contradicting 09-007r3:11.2.2p3), even if there's a nonintrinsic one of
> the same name in the module search paths?  Or is the only way to do it
> simply not to have such a one in any directory in the module search
> paths?
> 
> I have a 1/3-million line program in which we (perhaps unwisely) have
> "use IEEE_Arithmetic" in most modules.  For platforms that don't offer
> the intrinsic module yet, we've written our own.  It would be quite
> painful to go through the entire program and put either that or "use,
> intrinsic :: IEEE_Arithmentc" in place of what we have, controlled by a
> preprocessor variable.  Perhaps we should have put "use
> My_IEEE_Arithmetic" in each place, so we could put "use, intrinsic ::
> IEEE_Arithmetic" in that module.
> 
> If we were to add to the list in 16.3.1p2:
> 
>   o  is the name of the module or program in which the local identifier
>      appears
> 
> that would also solve the problem (and several others).  This wouldn't
> cause any trouble (for the standard) because module names only appear in
> MODULE, END MODULE, USE, and SUBMODULE statements.
> 

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101