(j3.2006) Intrinsic modules

[Craig Dedo]

Thanks, Kurt.  Your explanation makes a lot of sense.

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 Kurt W Hirchert
Sent: Saturday, November 21, 2009 19:06
To: fortran standards email list for J3
Subject: Re: (j3.2006) Intrinsic modules

Craig Dedo wrote:
> 	Does anyone remember why J3 chose to prefer nonintrinsic modules
> over intrinsic modules of the same name?
Yes, I remember.

Oh, you want to know what that reason was.  It was done this way to 
maintain compatibility with Fortran 90 and to promote continuing program 
portability.  Imagine, for example, that you have a Fortran 90 program 
that contains the statement

    USE  Barbie

to have access to procedures to heat shrimp.  (It wouldn't say 
USE,NONINTRINSIC::Barbie because that syntactic form wasn't available in 
Fortran 90, and it continues to be an unlikely choice for most modules 
because of its verbosity.)  Now imagine you tried to port this to a 
compiler provided by the Mattel corporation.  It might provide a 
[nonstandard] intrinsic module Barbie with procedures for manipulating 
fashion dolls and their accessories.  It would be no use to you in your 
desire for warm shrimp, so your program would break if intrinsic modules 
were chosen over nonintrinsic ones.  Even if you only gave preference to 
standard intrinsic modules, there's no guarantee that Mattel might not 
prevail upon the committee to standardize Barbie and Hotwheels in some 
future revision of the Fortran standard.  (If that isn't confusing 
enough, what if Barbie and Hotwheels were standardized not in a future 
revision of the Fortran standard, but in some other ISO standard, or 
even in a standard published by some other body.)

Although there are ways a vendor could justify providing a switch to 
reverse this rule, the bottom line is there probably isn't enough demand 
(and money) to get even one vendor to implement such a switch, let alone 
make it common enough to solve Van's problem.  Instead, I would suggest 
moving his nonintrinsic IEEE_Arithmetic module into a different 
directory from the rest of the source.  Then the inclusion/exclusion of 
that directory in his module search path becomes the switch to determine 
whether the nonintrinsic or intrinsic version of IEEE_Arithmetic is to 
be used.  This isn't quite as automatic as the switch Van asked for, but 
it is something he can do now, it eliminates the need to change his 
source code, and he probably has to change compiler switches on each new 
platform anyway.


-Kurt
_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3