lamson@sierra (03/10/88)
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::lamsonreeder@ut-emx.UUCP (William P. Reeder) (03/12/88)
In article <9872@steinmetz.steinmetz.UUCP>, lamson@sierra writes: > 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). I am reminded of the quote from Alan Perlis in "Epigrams on Programming": "When someone says, 'I want a programming language in which I need only say what I wish done,' give him a lollipop." <FLAME ON> My point is: DON'T PROTECT ME FROM MY OWN STUPIDITY! Everyone seems to think that everything they use should be idiot-proof. I vehemently disagree. There is NO substitute for careful program design, coding, and debugging. <FLAME OFF> If someone wants strong typing, tell them to use PASCAL or ADA or some other "computer scientist's" language. Failing that, find a compiler or program which can warn the programmer about type conflicts -- they do exist, perhaps even on the machine you and your friend are using. > 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! I often do write in assembly language -- and for some things I like it. And I find the idea of any committee doing design work appalling. > 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. No, we aren't saying you can't do anything new. But if you want to invent a new tool, invent a NEW tool: don't take away my old tools or bludgeon them into compliance with your ideas of how the world should look. Incidentally, I proposed in my comments to X3J3 that S8 be sent back to the drawing board with no holds barred and released as a new language, not an extension of FORTRAN. Would that make you happy? > Scott| ARPA: lamson@ge-crd.arpa > Lamson| UUCP: uunet!steinmetz!sierra!lamson -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.
lamson@sierra.uucp (scott h lamson) (03/14/88)
>William Reeder writes >> he didn't know the term "strong typing", that's what he wanted to do. >I am reminded of the quote from Alan Perlis in "Epigrams on Programming": > "When someone says, 'I want a programming language in which > I need only say what I wish done,' give him a lollipop." I don't believe I said this should happen automatically. I said I would make good use of a tool which enabled me to write code according to my own coding system, in this case one in which data items representing physical quantities in my application area were typed in a manner analogous to that observed in nature. And I would certainly not use it ALL the time anyway. Nor would I propose to require you or others to do the same. The only real points I tried to make are: there are things we can use the module feature of proposed F8x besides "include"ing "common" data. there are scientists interested in using these features if they become available >There is NO substitute for careful program design, coding, and debugging. No argument! Just there are good tools to support this, and poor ones. >I often do write in assembly language -- and for some things I like it. Got any assembly language coded BLAS for a SUN(w/fpa) or a VAX? I don't hear you sayin you would want to write everything in assembler, so we agree. > And I find the idea of any committee doing design work appalling. Both design by committee and democracy are known for their inefficiency and arriving at a comprimise (non-optimal) solution. I sent my comments to X3J3, so did you. I am prepared to live with the result. >Incidentally, I proposed in my comments to X3J3 that S8 be sent back to >the drawing board with no holds barred and released as a new language, >not an extension of FORTRAN. Would that make you happy? Unless I had some sort of migration path for the thousands of lines of fortran code I use/support/evolve, I don't think this would help me. At best I would have to continue using fortran for many projects, but some new language for any new projects. Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| GE DECnet: qtmvax::lamson