Path: utzoo!mnetor!uunet!steinmetz!sierra!lamson
From: lamson@sierra
Newsgroups: comp.lang.fortran
Subject: modules in f8x
Message-ID: <9872@steinmetz.steinmetz.UUCP>
Date: 10 Mar 88 12:17:28 GMT
Sender: news@steinmetz.steinmetz.UUCP
Reply-To: lamson@sierra ()
Organization: General Electric CRD, Schenectady, NY
Lines: 37



There has been a lot of discussion of the modules features lately, but
only in terms of how include capability can be done with modules, not
what new things become possible with modules.  Yesterday a physicist
working on light bulbs was talking to me about writing scientific
software in fortran such that you could not add "mass" to "length",
or mistakenly multiply "length" by "time" to get "velocity".  Although
he didn't know the term "strong typing", that's what he wanted to do.
He is NOT a computer scientist, repeat , a physicist (like me).
So I explained how in the proposed Fortran 8x you could define derived
data type "length", "time", and "velocity", set up procedures for
computing "velocity" from "length" and "time" and overloading the
"/" operator for "length" "/" "time" to return a type "velocity".
There would be no defined function for "length" * "time", so the 
compiler would flag this as an error.  And then he said all this can be
stored in some library somewhere to be used by different routines.
Yes, it's called a "module".

This appears to imply function call overhead for each computation
of "velocity".  Perhaps you could write your program with module A
that defined all these derived data types and catch some of the bugs
while testing.  Later when you are ready for production runs maybe
module B could be substituted which declared variables simply as
real rather than as "length", "time", and "velocity".  Then you avoid
the function call overhead.

I find the comments that Fortran 8x should only standardize existing
practice appalling.  If the first Fortran had done that, we'd still
be writing in assembly language!  Are these scientists saying we
cannot do anything new???  If so, we have deeper problems than the
F8x standardization.  The future is out there people, let's go for it.


        Scott|  ARPA:      lamson@ge-crd.arpa
       Lamson|  UUCP:      uunet!steinmetz!sierra!lamson
(518)387-5795|  GE DECnet: qtmvax::lamson