moshkovi@sanandreas.ecn.purdue.edu (Gennady Moshkovich) (07/26/90)
Please, don't consider my question offending, but why the hell in this world you people still using FORTRAN, while so many nice C around. Gene U U NN N I X X U U N N N I XX U U N N N I XX UUUU N NN I X X
ajayshah@aludra.usc.edu (Ajay Shah) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN Honestly, I can't imagine why Fortran is half as popular as it is. All old libraries can be linked into Pascal/C programs these days, which removes the only "fundamental" reason to hang on with fortran. I recently hit a research group which worked exclusively in fortran, and had to write fortran for a while, and was it a nightmare!! A language which has no data structures to speak of, no dynamic allocation, no recursion, everything passed by reference, no checking for number/type of arguments to functons/subroutines, no control over scoping..not to mention the silly syntactic irritations. God, it's just like COBOL; a dead language which clings to life on the rigidity of it's fossilised users. Only, in the case of COBOL you could ignore the disease since it was just business majors involved! _______________________________________________________________________________ Ajay Shah, (213)747-9991, ajayshah@usc.edu The more things change, the more they stay insane. _______________________________________________________________________________
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (07/26/90)
In article <11029@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes:
...
nightmare!! A language which has no data structures to speak of,
Many dialects of fortran do. (vms, sun, many more)
no dynamic allocation,
ditto. (vms, sun, many more)
no recursion
ditto. (most unix fortrans, IBM fortran G)
no checking for number/type of arguments to
ditto <lahey>, or via fortran "lint" programs (which predate C, and lint)
In addition, as argued about endlessly in a variety of groups, there
are specific things about fortran that make life easier for
optimizers. I suggest those interested look back at comp.compilers,
and old comp.lang.fortran and comp.arch groups to see the old
"debates". There is little gained by repeating them.
Folks code in fortran because it solves their problems well. Fortran
codes written in the early sixities can still run (often with no or
minimal mods) today. How many C codes written 10 years ago compile and
execute cleanly under ANSI C ? C++.
If history is any guide, 30 years from now, fortran codes will
continue to run with minimal mods (though with mods they will run
better). But that the C codes will have been massively overhauled.
If your job is to solve some "timeless" problem (like Finite Elements,
or matrix manipulation) which is the better language ?
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault | MTS --Only my work belongs to Sun* khb@chiba.Eng.Sun.COM
I Voted for Bill & | Advanced Languages/Floating Point Group (415 336 2648)
Opus<khb@eng.sun.com> "When the going gets Weird .. the Weird turn PRO"ttw@lambda.UUCP (Tony Warnock) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu>, moshkovi@sanandreas.ecn.purdue.edu (Gennady Moshkovich) writes: > Please, don't consider my question offending, but why the hell in this world > you people still using FORTRAN, while so many nice C around. > > Gene > > > U U NN N I X X > U U N N N I XX > U U N N N I XX > UUUU N NN I X X Fortran is used by people who like verbs in their clauses. More seriously, Fortran is used by people who are doing industrial strength computing such as number crunching, string manipulation, matrix stuff, complex variables, etc. When dealing with problems which are naturally expressed in multi-dimensional arrays, Fortran is the way to go. Fortran for full-contact programming!
gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (07/26/90)
In article <11029@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: >I recently hit a research group which worked exclusively in >fortran, and had to write fortran for a while, and was it a >nightmare!! A language which has no data structures to speak of, >no dynamic allocation, no recursion, everything passed by >reference, no checking for number/type of arguments to >functons/subroutines, no control over scoping..not to mention the >silly syntactic irritations. If you were using FORTRAN 77 to write programs which need the features it doesn't have, you're using the wrong tool. Use another one. If you are writing programs for which F77 is good, use it. It just so happens that the programs I write fit the F77 model well. BTW, checking the number/type of arguments to functions/subroutines is something which can be done. The Sun compiler doesn't do it, but running the code through f2c does. Followups to alt.religion.computers. -- "In fact you should not be involved in IRC." -- Phil Howard
jlg@lanl.gov (Jim Giles) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN People use Fortran instead of C for the same reason that people use English, French, or German instead of Esperanto. One: its a better, more expressive language (for the uses for which it is intended). Two: there is a large body of material already written in the language which would be difficult (and undesireable) to translate. Fortran vs. C has another feature which is not present in the natural language analogy (or maybe it is - judge for yourself): Fortran is _inherently_ more efficient for numerical/scientific work than C is. The C parameter passing mechanism implicitly coerces all arrays to pointers - which degrades the efficiency of the procedure being called. From article <11029@chaph.usc.edu>, by ajayshah@aludra.usc.edu (Ajay Shah): > [...] > Honestly, I can't imagine why Fortran is half as popular as it > is. All old libraries can be linked into Pascal/C programs these > days, which removes the only "fundamental" reason to hang on with > fortran. Pascal is a _much_ better language than C. I don't know why you mention them in the same context. In most respects, Pascal is on the opposite end of the language spectrum from C - Fortran would actually lie _between_ them in most respects. They _are_ similar in that neither on provides adequate support for array computations. > [...] no checking for number/type of arguments to > functons/subroutines, This is not a feature of Fortran - it is a feature of many implementations of Fortran. It is also a feature of all the C implementations I've ever seen. It is _not_ a valid complaint in this context. > [...] not to mention the > silly syntactic irritations. C has _many_more_ of these than Fortran does. Starting with expression valued assignment, control structures with begin-end (though C spells them as '{' and '}'), case-sensitive names, comments that wrap off the end of lines, statements that wrap off the end of lines, lack of a logical data type (which is a syntactic irritant because it causes C to require two complete sets of boolean operators), etc.. Note that I've only mentioned those problems which are _known_ from psychological and error survey studies to be detrimental to programmer productivity. A whole crowd of additional features (which are almost certainly bad but haven't been tested): over 40 operators, 15 levels of precedence, _really_ peculiar declaration syntax (I'm told that it looks this way so that the declaration will look like a use - but see what follows), _really_ peculiar syntax for using complex data items, etc.. This brings us to the _real_ reason that Fortran users don't switch to C - C is _NOT_ an improvement!! Fortran has a number of deficiencies, _some_ (very few) of which are corrected in C. But C introduces other deficiencies - worse than the ones it corrects. Quite rationally, Fortran users are waiting for a _BETTER_ language to show up before they switch. Fortran 90 had a chance to be this better language - but they blew it with a brain-dead pointer proposal (among other problems). J. Giles
ghe@comphy.PHYSICS.ORST.EDU (Guangliang He) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: | Please, don't consider my question offending, but why the hell in this world | you people still using FORTRAN, while so many nice C around. | | Gene | I'm not going to start another Fortran/C flame war here. I agree there are some nice C around. But on some machine, C just is not as good as Fortran. For example, the C compiler on the IBM AIX/370 don't support vectorization. (Correct me if I'm wrong). | | U U NN N I X X | U U N N N I XX | U U N N N I XX | UUUU N NN I X X Guangliang He ghe@PHYSICS.ORST.EDU hegl@ORSTVM.BITNET
ttw@lambda.UUCP (Tony Warnock) (07/26/90)
Another reason to prefer Fortran to C or Pascal
is that many of the Fortran operators are better
behaved than the analogous ones in C or Pascal.
For example: the .EQ. operator in Fortran is
an equivalence relation, that is, it is reflexive,
symetric, and transitive. It is not for C and for
Pascal. Actually in Pascal, at least, the analogous
predicate violates all three properties. This behavior
makes program analysis and optimization much harder.
Of course the reason is that Fortran is designed more
with mathematics in mind than most other languages. It
is not clear what the "equals" predicate in Pascal means.nfwarmerdam@spurge.uwaterloo.ca (Frank Warmerdam) (07/26/90)
At the company where I work we develop CFD codes to be run on many different clients computers. Everything from IBM 3090's, Crays, and down to Suns and various other workstations. We need extreme portability, and up to this time FORTRAN77 has been the most portable language available. Within another few years it will probable be safe to move to C, as Ansi compilers become widely available, but till then C is a real problem on many systems. Of course this does not mean that I *like* FORTRAN. :-) Frank Warmerdam frank\!rascl@watcgl.waterloo.edu ( I haven't thought of a witty .signature yet! )
jot@drydock.cray.com (Otto Tennant) (07/26/90)
One of the key facctors is multi-dimensional array processing. In many languages, a multi-dimensional array is not a "first-class" object. Instead, a two dimensional array is a vector of vectors, and so on. This means that there is a preferred direction for vecttorization. Of course, in principle, any well-defined computation can be compiled into efficient code (vectorized, autotasked (TM), or whatever.) On the other hand, for certain computations, Fortran expresses the computation more clearly for the purposes of the compiler. (I am *not* a compiler expert. Flames, or at least educational corrections, are welcome.)
davis@pacific.pacific.mps.ohio-state.edu ("John E. Davis") (07/26/90)
In article <14448@lambda.UUCP> ttw@lambda.UUCP (Tony Warnock) writes:
[STUFF DELETED]
More seriously, Fortran is used by people who are doing
industrial strength computing such as number crunching,
string manipulation, matrix stuff, complex variables, etc.
When dealing with problems which are naturally expressed
in multi-dimensional arrays, Fortran is the way to go.
Fortran for full-contact programming!
String Manipulation?????????? Then why have I posted a message asking for
string manipulation routines?
--
--John
bitnet: davis@ohstpy
internet: davis@pacific.mps.ohio-state.edusun@me.utoronto.ca (Andy Sun Anu-guest) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > >Gene > > >U U NN N I X X >U U N N N I XX >U U N N N I XX > UUUU N NN I X X When I feel like typing lots of trailing semi-colons, I use C. When I feel like typing lots of tabs (or 6 spaces), I use Fortran. Seriously, I myself use Fortran when most of the program is computation oriented, i.e. lots of equations, etc. When the program requires lots of string manipulations, or if I need to combine some low-level codes, then I'll use C. It also depends on how comfortable you are with the language. Pointers and dynamic allocations are handy, but they are also screw up your program (or even the machine, like a PC) real good if you are not careful. Andy _______________________________________________________________________________ Andy Sun | Internet: sun@me.utoronto.ca University of Toronto, Canada | UUCP : ...!utai!me!sun Dept. of Mechanical Engineering | BITNET : sun@me.utoronto.BITNET
sergio@sergio.uucp (Sergio Perrone/30000) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > >Gene > > >U U NN N I X X >U U N N N I XX >U U N N N I XX > UUUU N NN I X X Given the quality of your obviously advanced grasp of the English language, apparently gained through prolonged and vigorous exposure to a language featuring such literate and erudite constructs as '||' and 'char' and 'malloc', I'd say the answer is obvious. Marc ps Stupidity is a good keyword for your posting. --- Marc Andreessen, IBM AWD Austin, sergio@sergio.austin.ibm.com ---
pmontgom@euphemia.math.ucla.edu (Peter Montgomery) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the h*** in this world >you people still using FORTRAN, while so many nice C around. > Fortran has a large intrinsic function library. For example, Fortran's MAX and MIN functions can have two or more arguments of one type (integer or real), and most compilers generate inline code for these (evaluating each argument only once). C, Pascal, and Ada all lack these functions. Fortran's exponentiation operator ** allows exponents to be integer or real; many compilers check for the common cases of squaring and cubing. Fortran 77 has INT for converting to integer while rounding towards zero, and NINT for converting while rounding to nearest integer; Fortran 90x adds FLOOR and CEIL for rounding towards -infinity or +infinity. What other common languages support all four rounding modes, and allow you to mix them in one expression, as in i = CEIL(TAN(x)) - NINT(SQRT(y)) ? All of these languages lack adequate multiple precision arithmetic operations. For example, let a, b, c be integers with 0 <= a, b < c <= MAXINT, where MAXINT is the largest integer supported by an implementation. I want to get both the quotient a*b/c and the remainder a*b mod c, even though the intermediate product a*b may overflow. The mathematical definitions of these operations do not depend on the target machine, and the operations are essential when doing modular arithmetic (i.e., arithmetic mod c). Furthermore it is easy to generate code for these (e.g., two instructions plus operand accesses on a VAX or SUN 3, a function call on machines lacking double-length integer multiply and divide instructions). But language designers consistently omit them. -- -------- Peter L. Montgomery pmontgom@MATH.UCLA.EDU Department of Mathematics, UCLA, Los Angeles, CA 90024-1555
silvert@cs.dal.ca (Bill Silvert) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > That's easy. For one thing, novices can write Fortran code with minimal training, and we want scientists to be able to work with their own code without having to assume that programming experts understand what they want to do. Stuff like file-handling and I/O are hard, but equations are easy to handle. I write the main program and utility subroutines, my colleagues work on the guts of our ecological simulation models. Languages like C and even Pascal are not as easy for novices to understand, and portability is a major problem. I can port our models to all kinds of machines -- PC's, Mac's, ST's as well as mainframes -- without modification. -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
ooms@delgeo.UUCP (Frank Ooms) (07/26/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > >Gene > Why? because it would be stupid to write in a language that does not give the fastest code on the machine your using. (vectorization, paralellization, etc) that's why. -- /* Frank Ooms, +31 15-621554 * * ooms@delgeo.uucp * * ..!mcsun!hp4nl!delgeo!ooms */
mayne@VSSERV.SCRI.FSU.EDU (William (Bill) Mayne) (07/26/90)
In article <KHB.90Jul25115330@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: > > no checking for number/type of arguments to > >ditto <lahey>, or via fortran "lint" programs (which predate C, and lint) > >Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM This is good news! I and some others have been recently posting requests for just such tools as "lint" for fortran, but haven't seen any response. What is <lahey>? Where can I get some of this error checkers? Us users of Sun fortran are still looking for something as simple as a way to generate cross reference listings. (I finally wrote a simple one of my own using C, though I can think of several languages which would be better for this kind of task if I had access to and current familiarity with them...perl, rexx, icon, even snobol.) As for data structures, recursion, dynamic allocation, and (which had not been mentioned) access to command line arguments: Yes, various implementations of fortran provide some or all of these, but there is no standard for them so porting code is a real problem. I am no fan of fortran but I am forced to use it because I work in a scientific computing environment. But rather than either gripe about it or defend it I'll be happy to just get some help. I will say that once you get to know it fortran isn't so bad.
khb@chiba.Eng.Sun.COM (chiba) (07/27/90)
>for just such tools as "lint" for fortran, but haven't seen any response.
This has been posted *many* times.
Some of the current favorites:
IPT Fortran LINT 1096 East Meadow Circle, Palo Alto, CA 94303
415-494-7500
FORWARN Quibus Enterprises: Seems similar, from a promo blurb reading.
Probably has slightly uglier reporting
(one assumes the promo is as good as it
gets). 217 356 8876. Primary focus is the
PC market, but say unix versions are
available. $1200 would appear to be the
price, no discount structure info
available.
Flint(tm) Programming Research ltd:
Seems like a much more powerful tool (from
the promo lit) includes complexity
metrics, X11 interface and all sorts of
advisories about what constitutes good
portable code (beyond standard(s)
conformance). FAX 01 336 1151 voice
01-942-9242
FORCHECK Leiden University Box 9604
2300 RC Leiden
The Netherlands
31-71-276804 Claims similar to IPT's product.
Is said to be available on Suns and many
other platforms. I have no personal
experience with it.
FLOPPY/FLOW From CERN. FLOPPY was posted to
comp.sources.misc. Sun employees can get
it via the usual internal anon ftp site.
FLOW was not posted (and is the 'good
part').
Related tools of interest:
FOR_STRUCT Cobolt-Blue 2940 Union Ave Suite C San Jose CA 95124
408 723 0474. This is a "reverse engineering tool" to
use the COBOL lingo, viz. makes old code more readable
and maintainable. I have not used it myself.
SPAG I have reviewed SPAG, short overview is that SPAG is
quite handy ... alas not very unixlike (fixable with
some shell programming). (Sun employees note: Full
review is in the file called SPAG in the same directory
as this review). I like the results, and recommend this
tool with the caveat about non-unix interface...
US distributor: OTG
voice 717 222 9100
fax 717 229 9103
Authors:
Polyhedron Software Ltd
Magdalen House
98 Abingdon Road
Standlake
Witney
Oxon OX8 7RN
Tel 0865 300 579
There used to be stuff in the COSMIC catalog.
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault | MTS --Only my work belongs to Sun* khb@chiba.Eng.Sun.COM
I Voted for Bill & | Advanced Languages/Floating Point Group (415 336 2648)
Opus<khb@eng.sun.com> "When the going gets Weird .. the Weird turn PRO"khb@chiba.Eng.Sun.COM (chiba) (07/27/90)
...cross reference (Sunf77) With f77v1.3 and beyond there is an on-line tool called the source browser. Documentation is found in the Fortran User's Guide, and in the Browser User's Guide 800-3417-10 User Guide 800-3464-10 Browser cheers -- Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM It's Not My Fault | MTS --Only my work belongs to Sun* khb@chiba.Eng.Sun.COM I Voted for Bill & | Advanced Languages/Floating Point Group (415 336 2648) Opus<khb@eng.sun.com> "When the going gets Weird .. the Weird turn PRO"
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (07/27/90)
In article <11029@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: >Honestly, I can't imagine why Fortran is half as popular as it >is. All old libraries can be linked into Pascal/C programs these >days, which removes the only "fundamental" reason to hang on with >fortran. There's no standard for calling sequences from C to FORTRAN, especially for CHARACTER arguments. Our code has to run under VAX/VMS, IBM VM/CMS, Ultrix, Unix, AIX, and so on--so portability is important, and cross language calls are not currently portable. As people have already mentioned, there are optimizations that FORTRAN compilers can make which C compilers cannot (due to things like aliasing of subroutine types, and pointers). In addition, C (last I looked) doesn't guarantee the order of evaluation of expressions--the compiler reserves the right to commute and associate regardless of parentheses and such...so you sometimes have to split expressions up into lots of little pieces to force a particular order of evaluation. This makes C less natural than you might expect for some kinds of numerical calculations. I agree that FORTRAN is an upleasant language to use (especially if you stick to ANSI standard F77 for portability reasons), but there are still valid reasons to use it. -Dan Riley (riley@tcgould.tn.cornell, cornell!batcomputer!riley) -Wilson Lab, Cornell University
volovich@dendrite.Stanford.EDU (Buckaroo Banzai) (07/27/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > >Gene In the real world, FORTRAN is still your best or sometimes only answer - for instance - scientific computing is done primarily in FORTRAN. If you need any package to do anything, or if you want to use vector architecture, your only solution would be to use FORTRAN. Besides, what's wrong with it for numerically intensive purposes? IMHO, it's more suitable for this environment than C. Just my .02 worth, buddy. --------------------------------------------------------------------------- Gene Volovich | "We are the music makers. Academic Information Resources | We are the dreamers of dreams. Stanford University | - Willy Wonka ***************************************************************************
mjl@ut-emx.UUCP (Maurice LeBrun) (07/27/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. > >Gene Sorry, it WAS offending. You might have left off the 'stupidity' keyword if you truly didn't mean to be insulting. As many people have expressed, Fortran usually produces the fastest code on many high end systems. It is also typically far better supported than any other language, which is a bit unfortunate. The attitude that "there will never be any significant computation in any language other than Fortran" is still prevalent in some circles, and in fact has hampered getting a C++ compiler up on the Crays at NERSC (formerly called NMFECC). Different people deal with the inadequacies of Fortran in different ways. There are the vendor-supported compiler extensions. I prefer to use a preprocessor (such as Ratfor), so that the code maintains its portability. Use 'implicit none', if it's supported. Have the compiler load uninitialized variables with "non-numbers" so that an exception occurs if you use them. And so on... Also, it is much more difficult to intermix C and Fortran than it may seem (see other messages on this subject). And it is very system- dependent. This makes incrementally rewriting code in C much more of a hassle. Finally, in agreement with some of the other messages posted here, I'm not sure if switching to C gives enough "value" to be worth the effort. Now, C++ may be a different story.. Maurice LeBrun Institute for Fusion Studies mjl@fusion.ph.utexas.edu University of Texas at Austin
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (07/27/90)
On the whole, I'd like to defend Fortran against Pascal/C/you-name-it bigots, but I couldn't resist this. In article <164@kaos.MATH.UCLA.EDU>, pmontgom@euphemia.math.ucla.edu (Peter Montgomery) writes: > What other common languages support all four rounding modes, and allow you to > mix them in one expression, as in > i = CEIL(TAN(x)) - NINT(SQRT(y)) ? (a) Common Lisp: (setq i (- (ceiling (tan x)) (round (sqrt y)) )) [Oops. Common Lisp *does* support four rounding modes: round towards plus infinity (ceiling) round towards minus infinity (floor) round towards zero (truncate) round to nearest/even on tie (round) According to "Fortran 8X explained", NINT should be (round), but one F77 document I've seen claims that NINT is (roughly) NINT(X) = ISIGN(X)*CEIL(IABS(X)) which rather surprised me. I'm assuming that it's round to nearest.] (b) C: i = ceil(tan(x)) - nint(sqrt(y)); [Ok, only floor(), ceil(), and truncation are defined in the standard, but nint() is available in _some_ Cs. If it isn't, double nint(double x) { return ceil(x + 0.5) - (fmod(x*0.5 + 0.25, 1.0) != 0); } is all it takes.] I would point out that I was very surprised once when I discovered just how few of the things I thought of as F77 intrinsics were actually in the standard. (ERF doesn't seem to be in F90.)
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (07/27/90)
In article <7404@drydock.cray.com>, jot@drydock.cray.com (Otto Tennant) writes: > One of the key facctors is multi-dimensional array processing. > In many languages, a multi-dimensional array is not a "first-class" > object. Instead, a two dimensional array is a vector of vectors, > and so on. > This means that there is a preferred direction for vecttorization. Ahem. Not to knock Fortran, _but_ arrays are not first-class objects in Fortran 77, not like they are in Lisp or APL or Pop or Scheme. It has historically been the case that Fortran users _knew_ that "arrays are stored in column-major order", and if you have arrays which are large compared with your system's page size, it _still_ pays you to access Fortran arrays in the "easy" direction, e.g. DO 10 ICOL = 1, N DO 20 IROW = 1, M use A(IROW, ICOL) !IROW varies "faster" 20 CONTINUE 10 CONTINUE What if any difference this makes to vectorisation depends on how well your system handles non-unity strides. I _have_ encountered a compiler which could vectorise DO 10 ICOL = 1, N DO 20 IROW = 1, M A(IROW,ICOL) = B(IROW,ICOL) + C(IROW,ICOL) 20 CONTINUE 10 CONTINUE but if you switched the nesting of the DO statements it wouldn't.
BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (07/27/90)
In article <90Jul25.220640edt.20170@me.utoronto.ca>, sun@me.utoronto.ca (Andy Sun Anu-guest) writes: >In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >>Please, don't consider my question offending, but why the hell in this world >>you people still using FORTRAN, while so many nice C around. >> >When I feel like typing lots of trailing semi-colons, I use C. >When I feel like typing lots of tabs (or 6 spaces), I use Fortran. > My Fortran compiler gives you a choice: tabs, no semi-colons; or semi- colons, no tabs. Seriously, for the work I mostly do, Fortran is highly suitable. A lot of it is mathematical modelling or otherwise highly computational. I work with academics who are not computer professionals but may know SPSS or SAS, and Fortran is highly readable for them. Some of the statistical systems we use are Fortran-based (RATE and, I think, GLIM). Much of the existing software in my field is written in Fortran. I rarely have to design a user interface, but there are Fortran callable routines which allow screen operations, character manipulation and graphics. Most of all, over 90% of the programs I write will be used only once. Fortran is quick to code and easy to debug. There's no real reason not to use Fortran in my field. Barbara Vaughan
jac@gandalf..llnl.gov (James Crotinger) (07/28/90)
In article <34523@ut-emx.UUCP> mjl@emx.UUCP (Maurice LeBrun) writes: >In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >>Please, don't consider my question offending, but why the hell in this world >>you people still using FORTRAN, while so many nice C around. > As many people have pointed out, FORTRAN is well suited for writing numerical codes. C isn't necessarily as well suited for this. The biggest problems with C are the lack of a real multidimensional arrays and the lack of an intrinsic complex number type. In C, a multidimensional array is just a pointer to the first data element in the array. There is no mechanism for doing "dummy dimensioned" multidimensional arrays unless the subroutine which does this calculates the offsets explicitly. This stinks. The alternative is to use pointers to pointers to floats and pass these around. The problem is that will greatly inhibit optimization. Not only is there the usual alias problem, but the compiler has no way of knowing if the skip from the start of on row to the next is a constant (it doesn't have to be---a float** is a more general data structure than a simple array). On vectorizing computers this is a killer. >As many people have expressed, Fortran usually produces the fastest >code on many high end systems. It is also typically far better >supported than any other language, which is a bit unfortunate. I'm not sure what Maurice means by "supported" here. My experience has been that software development tools for C are for more developed on most systems (CRAYs excluded) than those for Fortran. I'd give my eye teeth for a Saber C type environment that would work with Fortran as well as C and C++. > The >attitude that "there will never be any significant computation in any >language other than Fortran" is still prevalent in some circles, and >in fact has hampered getting a C++ compiler up on the Crays at NERSC >(formerly called NMFECC). > Yep, Fortran, like COBOL, has a lot of inertia. Not only is there a large body of Fortran code (and mixing Fortran and C is quite nonportable) in existance, there are also a large number of older programmers who just plain don't want to switch. From the perspective of a Fortran programmer, C++ addresses many of the shortfalls of C [functional shortfalls..if you don't like C's syntax, you won't like C++'s, but this is a subjective matter]. The down-side is that it is not at all clear C++ code will be easy to optimize/vectorize. > >Maurice LeBrun Institute for Fusion Studies >mjl@fusion.ph.utexas.edu University of Texas at Austin Jim -- ========================================================================= James A. Crotinger Lawrence Livermore National Laboratory // jac@gandalf.llnl.gov P.O. Box 808; L-630 \\ // (415) 422-0259 Livermore CA 94550 \\/
ahlstrom@oscar.ccm.udel.edu (07/28/90)
In article <1990Jul26.195210.17918@portia.Stanford.EDU>, volovich@dendrite.Stanford.EDU (Buckaroo Banzai) writes... >In article <1990Jul25.174153.16896@ecn.purdue.edu> moshkovi@cn.ecn.purdue.edu writes: >>Please, don't consider my question offending, but why the hell in this world >>you people still using FORTRAN, while so many nice C around. >> Amazing, isn't it, how one person can post the smallest piece of garbage and thus begin an argument which is not only riddiculous, but costs thousands of dollars as well. If you want to use C, go ahead. There's a news group you can read and you can bash FORTRAN _over_there_ all you like. I'm sure that most of the people who read this group are looking for advice in programming rather than a childish debate on which is better: FORTRAN or C. Both have their uses and their users. So why not stop wasting everyone's time, energy, and money, and end this "debate"? *************************************************************************** Lee M. Ahlstrom Center for Composite Materials University of Delaware "It is always darkest before it goes ahlstrom@oscar.ccm.udel.edu completely black." ***************************************************************************
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (07/29/90)
In article <14449@lambda.UUCP>, ttw@lambda.UUCP (Tony Warnock) writes: > For example: the .EQ. operator in Fortran is > an equivalence relation, that is, it is reflexive, > symetric, and transitive. It is not for C and for > Pascal. If that is a damning criticism of C and Pascal, please take into acount the fact that .EQ. is *NOT* an equivalence relation in Fortran either. Equivalence fails in at least two ways: (a) it is easy to find expressions e1, e2, e3 such that e1 .EQ. e2 is legal (and true) and e2 .EQ. e3 is legal (and true) but e1 .EQ. e3 is not permitted by the standard. (b) it is easy to find three CONSTANTS c1, c2, c3 such that c1 .EQ. c2 is true and c2 .EQ. c3 is true but c1 .EQ. c3 is false in the majority of Fortran implementations. The only Fortran I've ever used where this was not so was that on the B6700. (Hint: on a B6700 REAL variables are cheaper than INTEGERs.) Point (a) also applies to C and Pascal, in the sense that the corresponding e1' = e3' or e1' == e3' is not fully defined. Point (b) doesn't apply to (Classic) C. -- Science is all about asking the right questions. | ok@goanna.cs.rmit.oz.au I'm afraid you just asked one of the wrong ones. | (quote from Playfair)
rosenkra@convex1.convex.com (William Rosencranz) (07/29/90)
---
what the heck, i might as well add my 2 cents...
having programmed in fortran for close to 20 years (sheesh!) and C for
about 6, i use both languages for different reasons. it is practically
impossible to _easily_ program systems software, at least unix systems
software, in fortran. go ahead and try to use sockets in fortran. i dare
you! i know, i have. C has more clearly defined, or should i say more
visible, data structures via structs and unions. i also find it better
for string operations and things like parsing. C was developed to make
unix portable. it has done that remarkably well, IMHO. it could probably
have been done with fortran, too, i suspect. it would not be _better_
in fortran, just _different_. i have worked on pseudo operating systems
in fortran, so i know it can be done.
fortran, on the other hand, is still THE language for number crunching,
having things built in like complex data types,
though vectorizing C compilers are getting as good, provided you write
C like fortran and not as convoluted as things can get in C. there is
a huge investment in fortran, which cannot be dismissed. it is just not
good business to do so. yes, i _am_ a capitalist!
in a significant application involving parsing (i.e. reading input data)
and computation, i'd probably try and use both. then tools like yacc and
lex become available, speeding the development process which saves $$$,
increasing profits, making the user's life easier (with more sophisticated
parsers), etc., which are all really the name of the game.
the bottom line is that good programming is good programming, regardless
of the language. i have seen (and done :-) abuses in both languages so
i would not say it is any inherent difficiency of a language that is the
problem, rather the user of the language.
i feel comfortable with both. each has their strong (and weak) points.
this should not be a religious issue if you are rational about it.
(down with language bigots!). you can do just about anything in one
language that can be done in the other (and visa versa). it just boils
down to which is the more productive tool to use. for me it is not an
academic or theoretical decision. it is a business decision as it should
be for most any serious programmer who programs for a living. if i can
get a job done faster with C, meeting specs, i use C so i can either
have more free time or can move on to the next project. same goes
for fortran. that's why there is chocolate and vanilla!
i consider byself pretty unbiased regarding languages, though i admit
that i curse at fortran more than C, primarily because i had been
using C more for the past 4-5 years. what i should really do is curse
at myself (or the author of the code i am trying to debug :-).
BTW: f2c is a must for bilingual programmers. it is really an excellent
tool. it is also written in C.
no offense intended to anyone here. my opinions only....
-bill
rosenkra%c1yankee@convex.com
(note that companies like convex make both vectorizing/parallel C and
fortran compilers that get better and better so the distinctions between
the languages tend to blur over time. progressive standards also tend to
improve languages as well. i have just discovered Ada, which i thought
i would really hate, but now find it quite an interesting language, once
i took the time to understand it, both syntactically as well as why it
was developed in the first place.)
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comrap@csadfa.cs.adfa.oz.au (Robert Pearson) (08/01/90)
From article <65460@lll-winken.LLNL.GOV>, by jac@gandalf..llnl.gov (James Crotinger): > As many people have pointed out, FORTRAN is well suited for writing > numerical codes. C isn't necessarily as well suited for this. > >>As many people have expressed, Fortran usually produces the fastest >>code on many high end systems. It is also typically far better >>supported than any other language, which is a bit unfortunate. > > I'm not sure what Maurice means by "supported" here. My experience > has been that software development tools for C are for more developed > on most systems (CRAYs excluded) than those for Fortran. I'd give > my eye teeth for a Saber C type environment that would work with > Fortran as well as C and C++. just to add my opinions I have had many years programming fortran from the very early CDC through to current supers. At the moment I have about 12,000 lines of code (most C ) for a computationally intensive task which can be written to be suitable for a vector processor. BUT the main structure is a tree. ideal for pointers to complex structures. HOWEVER multidimensional arrays in C are a PAIN espescially if one wants to pass part of the array FORTRAN A(30,30,50) call b (a(1,1,nold) where in b is a(30,30) C does work b(&a[nold][0][0]); and can actually let the fortran treat 'a'as a variable dimension array BUT tfortran automatically converts most of my code to vectors C requires all sorts of nasty tricks I have had to experiment to find code that will give a vector and worse in one part of the code will give vector; splitting up not necessarily works as vector. chnging from defined to global or local may also change the vector ???? : wish I understood it all !!!! the problem is not the compilers so much as the specification that ARRAYS and POiNTERS are EQIVALENT how the people who write any compilers for vector processors that can handle this problem is past me, and I am actually amazed that they have done relatively well for those interested the code has been published in IJHSC Vol 2 85-100 My solution would be to write C for the pointers and convert to fortran for the rest. Also a PAIN Robert Pearson ISD: +61 62 68 8171 STD: (062) 68 8171 Dept. Computer Science Telex: ADFADM AA62030 University College ACSNET: rap@csadfa.oz Aust. Defence Force Academy UUCP: ...!uunet!munnari!csadfa.oz!rap Canberra. ACT. 2600. ARPA: rap%csadfa.oz@uunet.uu.net AUSTRALIA CSNET: rap@csadfa.oz Robert Pearson ISD: +61 62 68 8171 STD: (062) 68 8171 Dept. Computer Science Telex: ADFADM AA62030 University College ACSNET: rap@csadfa.oz Aust. Defence Force Academy UUCP: ...!uunet!munnari!csadfa.oz!rap
staff@cadlab.sublink.ORG (Alex Martelli) (08/05/90)
>There's no standard for calling sequences from C to FORTRAN, especially >for CHARACTER arguments. Our code has to run under VAX/VMS, IBM VM/CMS, >Ultrix, Unix, AIX, and so on--so portability is important, and cross >language calls are not currently portable. I built a set of C macros for this, which currently make C/Fortran calls with character parameters (and other tough cases, such as procedures as parameters) fully portable across the wide range of platforms CAD.LAB products support - all you mentioned, except CMS, plus OS/2, Apollo DOMAIN, etc. The syntax on the C side gets ugly, but it DOES work! Takes some days poring over the disassembled output of the Fortran compiler, that's all... For example: long FTN(example) (DCA(x), y, DCA(z) DCL(x) DCL(z)) DCHAL(x); long *y; DCHAL(z); { /* other local variables */ STCHA2(x, z); /* now you can use CHA(x), CHA(z) as the arrays of chars that you are passed, LEN(x) and LEN(z) as their int lengths (rvalues) */ } On many f77 compilers, DCA(x) is x, DCL(x) is ,L/**/x (note the comma and the token-pasting trick), DCHAL(x) is char *x; long L/**/x (no closing semicolon), STCHAn() is empty for all n, CHA(x) is x, LEN(x) is L/**/x. In other machines, token pasting is ANSI ##, and in some DCA(x) is x,L/**/x with DCL(x) empty; on VAX, DCHAL(x) is a pointer to a descriptor-structure; in OS/2, STCHAn() declares the L##x, which are NOT passed as arguments, AND initializes them from the global array where Microsoft Fortran hides them. Oh, and FTN() itself is "transparent" for Vax and HP, pastes an underline for Sun, attaches the "fortran" keyword for Microsoft, and so on and on. I also have macros for commons, etc. The ONLY thing I have not been able to make universally portable are functions returning single-precision reals; double-precision must be used (for PARAMETERS, no problems, since only a POINTER to them is passed). I have not considered the reverse interface, C calling Fortran, since we use C for "low-level" stuff and Fortran for application-level code, thus the C-calls-Fortran is a quite minor need for us. -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).
smryan@garth.UUCP (sous-realiste) (08/08/90)
>Please, don't consider my question offending, but why the hell in this world >you people still using FORTRAN, while so many nice C around. Just say NO! You might as well ask why so many people use cocaine. Man, it gives me lots of energy, I can move so fast. Dangerous at any speed. C (and Unix), on the other hand, is a successful ATT experiment on crippling on machines equal. Most people use Fortran/C/Cobol/Pascal/... because it's easier than learning a new language. -- Her somber eyes consider all ||/+\==/+\|| Steven Ryan that loom and tower, large and tall.||\=/++\=/|| ...!uunet!ingr!apd!smryan Her everyday is always new ||/=\++/=\||...!{apple|pyramid}!garth!smryan and fills her eyes of frail blue. ||\+/==\+/|| 2400 Geng Road, Palo Alto, CA
smryan@garth.UUCP (sous-realiste) (08/09/90)
>Of course, in principle, any well-defined computation can be compiled >into efficient code (vectorized, autotasked (TM), or whatever.) >On the other hand, for certain computations, Fortran expresses the >computation more clearly for the purposes of the compiler. Advanced languages (neither Fortran nor C) can express computation even clearer than Fortran. For example Algol68 would permit the compiler to define the operator `+' on two vector arguments. It could then generate an inline sequence for the operator, so that one could have `a[m,] + b[,n]' expand into (on a Cy205) gather: b -> temp addv: a+temp -> temp Apparently Fortran90 will also permit such. However will Fortran90 permit `p[m,] and q[,n]'? gather: b -> temp andv: a&temp -> temp And many other languages also regard themselves as tool for the programmer rather than challenge. If a Fortran is an infantile disorder, what is C? Don't worry, though, my code just needs a fix. Just one more fix, please. -- Her somber eyes consider all ||/+\==/+\|| Steven Ryan that loom and tower, large and tall.||\=/++\=/|| ...!uunet!ingr!apd!smryan Her everyday is always new ||/=\++/=\||...!{apple|pyramid}!garth!smryan and fills her eyes of frail blue. ||\+/==\+/|| 2400 Geng Road, Palo Alto, CA
hirchert@ux1.cso.uiuc.edu (Kurt Hirchert) (08/11/90)
In article <662@garth.UUCP> smryan@garth.UUCP (sous-realiste) writes: ... >For example Algol68 would permit the compiler to define the operator `+' on >two vector arguments. It could then generate an inline sequence for the >operator, so that one could have `a[m,] + b[,n]' expand into (on a Cy205) > > gather: b -> temp > addv: a+temp -> temp > >Apparently Fortran90 will also permit such. However will Fortran90 permit >`p[m,] and q[,n]'? > > gather: b -> temp > andv: a&temp -> temp > a(m,:)+b(:,n) and p(m,:).and.q(:,n) are both valid expressions in Fortran 90. (Of course, the row of a has to have the same length as the column of b and similarly for p and q.) _All_ elemental operations have been so extended in Fortran 90. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
maine@elxsi.dfrf.nasa.gov (Richard Maine) (08/14/90)
On 5 Aug 90 09:25:05 GMT, staff@cadlab.sublink.ORG (Alex Martelli) said: >There's no standard for calling sequences from C to FORTRAN, especially >for CHARACTER arguments. Our code has to run under VAX/VMS, IBM VM/CMS, >Ultrix, Unix, AIX, and so on--so portability is important, and cross >language calls are not currently portable. Alex> I built a set of C macros for this, which currently make C/Fortran Alex> calls with character parameters (and other tough cases, such as Alex> procedures as parameters) fully portable across the wide range of Alex> platforms CAD.LAB products support - all you mentioned, except CMS, Alex> plus OS/2, Apollo DOMAIN, etc. The syntax on the C side gets ugly, Alex> but it DOES work! Takes some days poring over the disassembled Alex> output of the Fortran compiler, that's all... Well..., that's not quite all. I'll ignore issues such as that I often send out code to people who sometimes have to be helped with how to run the compiler, much less pour over its disassembled output. I'll also ignore the issue of portability to systems where both compilers are not even installed (I've seen plenty of such systems). Talking about the argument passing and entry point naming only addresses the easiest half of the problem (I didn't say easy; I said easiest). The hard part is when you want to do i/o during such interlanguage calls. I didn't see that discussed in these macros at all. The c i/o routines tend to assume that they were initialized by a c main program, and conversely for the fortran i/o routines. Doing i/o from a c subroutine called from a Fortran main (or vice-versa) is real tricky. Yes, I've seen it done successfully on some systems, but I'm unconvinced that it can be done at all on other systems, much less portably. If you've managed to find a way to do this with any degree of portability, I'll be very, very impressed (that is, after I get over being dubious). Restricting the solution to solely Unix systems doesn't count as being portable enough, by the way. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]
jlg@lanl.gov (Jim Giles) (08/16/90)
> [...] > There's no standard for calling sequences from C to FORTRAN, especially > for CHARACTER arguments. Our code has to run under VAX/VMS, IBM VM/CMS, > Ultrix, Unix, AIX, and so on--so portability is important, and cross > language calls are not currently portable. This is a fault with the design of C (and all other HLLs in fact). If I were designing a new HLL, I would make Fortran call compatibility a required part of the language specification. That is, if the target machine has a Fortran implementation, any conforming implementation of _my_ language would be required to be able to interface to it in a uniform manner. The same goes for C, Pascal, etc.. Any time you design a new language, call compatibility with other popular languages in common use by your target user community should be a priority. Else, you'll have an obsticle in the path of people trying to use your new language. Of course, if you don't see this as a problem with the design of C, then you'll have to admit that Fortran users are not part of the proper target user community of C. J. Giles
ags@seaman.cc.purdue.edu (Dave Seaman) (08/16/90)
In article <60202@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >If >I were designing a new HLL, I would make Fortran call compatibility a >required part of the language specification. That is, if the target >machine has a Fortran implementation, any conforming implementation of >_my_ language would be required to be able to interface to it in a >uniform manner. So what do you do if the target machine has more than one Fortran implementation and the different versions are not even compatible with each other? I suppose you could rule that the first Fortran implementation is the only one allowed, thus ruling out improvements in the implementation that would change the interface. But what if there is no vendor-supplied Fortran, and only third-party implementations exist? Do you say the first one to ship is the official version, and all others are barred from the market unless they change their interface to conform? -- Dave Seaman ags@seaman.cc.purdue.edu
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (08/16/90)
In article <13035@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: >In article <60202@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>If >>I were designing a new HLL, I would make Fortran call compatibility a >>required part of the language specification. That is, if the target >>machine has a Fortran implementation, any conforming implementation of >>_my_ language would be required to be able to interface to it in a >>uniform manner. > >So what do you do if the target machine has more than one Fortran >implementation and the different versions are not even compatible with each >other? > >I suppose you could rule that the first Fortran implementation is the only one >allowed, thus ruling out improvements in the implementation that would change >the interface. > >But what if there is no vendor-supplied Fortran, and only third-party >implementations exist? Do you say the first one to ship is the official >version, and all others are barred from the market unless they change their >interface to conform? > I would require that ANY language be compatible with the vendor's standard calling convention - at least with a command-line switch. Where the vendor's conventions is abysmally slow (i.e. VMS) I would have an optional faster one. In the PC marketplace, vendors that don't follow Microsoft's convention (i.e. Ryan=McFarland) get mercilessly bad press. Doug McDonald
ags@seaman.cc.purdue.edu (Dave Seaman) (08/17/90)
In article <1990Aug16.150718.15055@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <13035@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: >>But what if there is no vendor-supplied Fortran, and only third-party >>implementations exist? Do you say the first one to ship is the official >>version, and all others are barred from the market unless they change their >>interface to conform? >I would require that ANY language be compatible with the vendor's >standard calling convention - at least with a command-line switch. >Where the vendor's conventions is abysmally slow (i.e. VMS) I >would have an optional faster one. But what if there is more than one "vendor's standard calling convention?" For example, there was the CDC RUN compiler, which was later replaced by the incompatible FTN3/FTN4/FTN5 series. A more recent example is DEC Ultrix, which has the f77 compiler and also the incompatible VAX FORTRAN "fort" compiler (ported from VMS). If you take away either of those, you will alienate large numbers of users. When you start mixing languages, things get even more complicated. There may be a vendor's standard method for passing variables in Fortran, but that does not imply a vendor's standard method for sharing objects in higher-level languages. -- Dave Seaman ags@seaman.cc.purdue.edu
jlg@lanl.gov (Jim Giles) (08/17/90)
From article <13035@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > In article <60202@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>If >>I were designing a new HLL, I would make Fortran call compatibility a >>required part of the language specification. That is, if the target >>machine has a Fortran implementation, any conforming implementation of >>_my_ language would be required to be able to interface to it in a >>uniform manner. > > So what do you do if the target machine has more than one Fortran > implementation and the different versions are not even compatible with each > other? I'm not interested in whether the Fortrans (or Cs, Pascals, Modulas, etc.) are compatible with each other, I only want them to be _callable_ from each other on a way which appears consistent from the HLL point of view. If this means that several different bridges to Fortran have to be present on the low-level for different Fortrans, that tough. Of course, implementors who avoid use of industry (or vendor) standard calling sequence conventions are shooting themselves in the foot by making their produce harder to use from within existing environments. This is all beside the point that I was making. That is, there should be no _high_level_ impediments to mixing code (like incompatibilities of common data types where is difference is visible at the high level). An example of this is character variables in Fortran an C. Both languages have fixed sized character variables but C provides a set of routines which expect null termination on all strings. The use of this null termination is so common in C that people think of the null as a required part of the C character value (in fact, the C character constant constructor (quote marks) puts the null on automatically). Cramming this null onto full Fortran variables is the problem most people refer to when they consider the problem of Fortran/C character compatibility. Note: it is not only not _necessary_ to add null termination, but it is actually _more_ efficient _not_ to use null termination and to carry the present active length of a string around explicitly instead. In C this would require the use of the mem???() functions (ie. memcmp(), memcpy(), etc.) instead of the str???() functions. In Fortran, this is already what most people do (using more convenient - built-in - constructs). J. Giles
ELEYC@latvax8.lat.oz (08/17/90)
In article <1990Jul25.174153.16896@ecn.purdue.edu>, moshkovi@sanandreas.ecn.purdue.edu (Gennady Moshkovich) writes: > Please, don't consider my question offending, but why the hell in this world > you people still using FORTRAN, while so many nice C around. > > Gene I am not going to say if FORTRAN is better or worse than C. However, no matter how much effect is put into the development of a language, it is not going to be perfect. There are always some advantages and shortcomes with it. The reason why I stick on FORTRAN is that I got familiar with FORTRAN before C came along. I just can't borther to learn another language and change all the programs I have written in FORTRAN, to save, perhaps, 0.5mins of CPU time which is not significant to me at all. y.c.-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`` "The journey of thousand miles begins with one step." ......Lao-Tse ``~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ / /__\ -----` Yong-qiang Cai, Electron Physics Group Ph:(03)479,1430 /| //\` |__ Physics Department, Latrobe University Telex:(AA)33143 | /\/& | & Bundoora, Victoria, Australia 3083.... Fax:(03)4785814 | _/\_ _/ j Electronic Mail: ACSnet!eleyc@latvax8.lat.oz *//////* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ags@seaman.cc.purdue.edu (Dave Seaman) (08/18/90)
In article <60344@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <13035@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): >> So what do you do if the target machine has more than one Fortran >> implementation and the different versions are not even compatible with each >> other? >I'm not interested in whether the Fortrans (or Cs, Pascals, Modulas, >etc.) are compatible with each other, I only want them to be _callable_ >from each other on a way which appears consistent from the HLL point of >view. If this means that several different bridges to Fortran have to >be present on the low-level for different Fortrans, that tough. Of >course, implementors who avoid use of industry (or vendor) standard >calling sequence conventions are shooting themselves in the foot by >making their produce harder to use from within existing environments. The two examples I gave of incompatible Fortrans were both cases of vendor-supplied Fortrans that ran on the same machines and were reasonably compatible at the source language level (though with slightly different extensions), but which were fundamentally incompatible at the object code level. They are definitely not callable from each other. An implementor of some other language (Pascal, say) does not need to support every incompatible version of Fortran on the machine. It's more cost-effective to pick just one Fortran to support. -- Dave Seaman ags@seaman.cc.purdue.edu
cik@l.cc.purdue.edu (Herman Rubin) (08/19/90)
In article <13071@mentor.cc.purdue.edu>, ags@seaman.cc.purdue.edu (Dave Seaman) writes: > In article <60344@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >From article <13035@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > >> So what do you do if the target machine has more than one Fortran > >> implementation and the different versions are not even compatible with each > >> other? > >I'm not interested in whether the Fortrans (or Cs, Pascals, Modulas, > >etc.) are compatible with each other, I only want them to be _callable_ > >from each other on a way which appears consistent from the HLL point of > >view. If this means that several different bridges to Fortran have to > >be present on the low-level for different Fortrans, that tough. Of > >course, implementors who avoid use of industry (or vendor) standard > >calling sequence conventions are shooting themselves in the foot by > >making their produce harder to use from within existing environments. > The two examples I gave of incompatible Fortrans were both cases of > vendor-supplied Fortrans that ran on the same machines and were reasonably > compatible at the source language level (though with slightly different > extensions), but which were fundamentally incompatible at the object code > level. They are definitely not callable from each other. > An implementor of some other language (Pascal, say) does not need to support > every incompatible version of Fortran on the machine. It's more cost-effective > to pick just one Fortran to support. There is a not too expensive alternative to this problem, and other interface problems. That is, to put the necessary software to handle various call and return procedures in the various compilers. Each compiler expects its input arguments in a clearly defined manner, and also its register saving procedures, and there is no good reason why this information could not be incorporated into another compiler. This could even be used for machine language calls. I did not say that there were no costs, in particular efficiency costs, involved. But it provides a kludge which is easy to implement. It also gets around the problems of name changes by the compiler in many cases. In the UNIX systems I have seen, in general a Fortran program cannot call a C program because of the name problem. It may be necessary to produce these interfaces in assembler, but this will be a small cost compared to the alternatives of language translation or recompilation. Many algorithme at Purdue were not callable from one Fortran to another, and this could have been handled. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
In article <1990Aug16.150718.15055@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > I would require that ANY language be compatible with the vendor's > standard calling convention - at least with a command-line switch. > Where the vendor's conventions is abysmally slow (i.e. VMS) I > would have an optional faster one. What if the vendor didn't ship any compiler product or linkable files until after a second party had finished their implementation (using cross-compilers from another machines)? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
jlg@lanl.gov (Jim Giles) (08/24/90)
From article <13071@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > [...] > The two examples I gave of incompatible Fortrans were both cases of > vendor-supplied Fortrans that ran on the same machines and were reasonably > compatible at the source language level (though with slightly different > extensions), but which were fundamentally incompatible at the object code > level. They are definitely not callable from each other. I'll bet they _were_ callable from each other - it may have taken a substantial bridge, but it could be done. There is obviously no HLL visible incompatibility between the _standard_ parts of the two languages (the only parts that you can legitimately expect to be call compatible anyway). > [...] > An implementor of some other language (Pascal, say) does not need to support > every incompatible version of Fortran on the machine. It's more cost-effective > to pick just one Fortran to support. However, supporting _all_ versions of Fortran is probably not much harder than supporting one. I would expect the first to be the hardest, each one after would be easier. Still, Pascal (ISO anyway) hasn't many high-level incompatibilities with Fortran. So the two languages should be mutually callable (if you stick to data types they have in common). The only case I would consider even interesting (ie. slightly challenging) would be the fact that Pascal multidimensional arrays are row-major while Fortran's are column-major. This probably doesn't need conversion though - users can just transpose the indices. Now, if Pascal had introduced complex numbers and made a constraint that such numbers _must_ be implemented as pairs of floating point values with the imaginary part _first_ - then you'd have an incompatible design feature. That is what my original point was: a new language should not introduce high-level features which directly conflict with the constraints of the same feature in another popular language. Not unless the new design is specifically targeted for different users and nobody anticipates _ever_ mixing the two. J. Giles
ags@seaman.cc.purdue.edu (Dave Seaman) (08/24/90)
In article <60978@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <13071@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): >> [...] >> The two examples I gave of incompatible Fortrans ... >> were fundamentally incompatible at the object code >> level. They are definitely not callable from each other. > >I'll bet they _were_ callable from each other - it may have taken a >substantial bridge, but it could be done. There is obviously no HLL >visible incompatibility between the _standard_ parts of the two >languages (the only parts that you can legitimately expect to be >call compatible anyway). If, by "a substantial bridge", you mean an a special intelligent version of the linking loader that would: 1. cause all subroutine/function calls to be routed through a bridge routine that would examine the argument lists and transform them, when necessary, into the form expected by the called routine, and 2. transform all I/O requests to the nonresident I/O system (the one not initialized by the main program) into the equivalent call in the other system (which would probably require an extensive table of routines to watch for, and specially-written library routines to do the equivalent in the other I/O system, since there is no 1-1 correspondence between the two), and 3. resolve name conflicts at load time caused by different routines being loaded from different libraries with the same name but different functions, then I suppose you are right in saying that it could be done. What would be your reaction if a vendor sold you a product with the claim that something "could be done", and you later found out that doing it would require several man-years of reprogramming? -- Dave Seaman ags@seaman.cc.purdue.edu
jlg@lanl.gov (Jim Giles) (08/28/90)
From article <13293@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > [...] > 1. cause all subroutine/function calls to be routed through a bridge > routine that would examine the argument lists and transform them, > when necessary, into the form expected by the called routine, and Doesn't _have_ to be the loader. Many implementations have the capability to do this sort of thing in the compiler. Some Pascals, for example, have a way of declaring a routine to be a Fortran external. If there were several different Fortrans on the target machine, there is not reason not to have a distinct way of declaring each. On the other hand, the "smarts" could be built into a loader which would relieve the compiler writer from the need to do all this and place the call sequence compatibility problem into a single tool for all language implementations to use. > [...] > 2. transform all I/O requests to the nonresident I/O system (the one > not initialized by the main program) into the equivalent call in > the other system (which would probably require an extensive table > of routines to watch for, and specially-written library routines to > do the equivalent in the other I/O system, since there is no 1-1 > correspondence between the two), and This is a different issue from call sequence compatibility. What you are implying is that unless you can successfully do I/O from both of the two languages/implementations, it is never worth trying to mix the two. However, the _vast_ majority of mixed language usage is not of this form. If I have (say) a Fortran Runge-Kutta routine that I want to use from Pascal, I don't want to have to rewrite the thing, I want to just call it. Call sequence compatibility is not _everything_, but it _is_ a valuable capability. Even so, it is usually not all _that_ hard to do I/O from both languages. To be sure, it is not simple. But, it's not "man-years" of effort either. > [...] > 3. resolve name conflicts at load time caused by different routines > being loaded from different libraries with the same name but > different functions, This clearly doesn't have _anything_ to do with the subject we are discussing. This problem can arise even if all the libraries and main codes are writen in the _same_ language and for the _same_ implementation. However, if you want to discuss this topic, I have a solution to propose. Add 'module' support to your languages (as from Modula). Then, each different library can be compiled as a separate module. The linker can avoid conflicts because it knows that routines in different modules are different - even if they have the same name. The default libraries for a given implementation are 'automatically' referenced modules for code compiled with that implementation. Except for synchronization problems (I/O to the same file from distinct languages), this solution even fixes the problem cited in point <2> above. J. Giles
ags@seaman.cc.purdue.edu (Dave Seaman) (08/28/90)
In article <61279@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [Re: "a substantial bridge" = superintelligent loader] >Doesn't _have_ to be the loader. Many implementations have the >capability to do this sort of thing in the compiler. Some Pascals, >for example, have a way of declaring a routine to be a Fortran >external. If there were several different Fortrans on the target >machine, there is not reason not to have a distinct way of declaring >each. Since you say you are not trying to support both I/O systems, the alternate approach becomes more feasible. I can understand wanting to call Fortran routines from a Pascal program, but what is the point in trying to call one Fortran from another, especially when they are wildly incompatible? Isn't it easier just to recompile everything using a single compiler? My point in introducing the two-incompatible-Fortran examples was that you can't solve all the incompatibility problems by requiring all languages to be compatible with the vendor-supplied Fortran on the machine, because there may be more than one vendor-supplied Fortran, and they may be incompatible. I don't see how arranging to call one Fortran from the other solves compatibility problems with other languages. By the way, the compatibility problem is even worse than I indicated. It is reasonable to suppose that two Fortrans on the same machine will use the same representations for types INTEGER, REAL, COMPLEX, DOUBLE PRECISION and CHARACTER. The same does not hold for type LOGICAL. Beyond the requirement that LOGICAL variables take the same amount of storage as INTEGER and REAL variables, the standard places no restrictions on the internal representation and there is no single "best" way to implement the type. For example, one implementation may focus on the least significant bit, using 0 for .FALSE. and 1 for .TRUE. Another may focus instead on the sign bit, using +1 for .FALSE. and -1 for .TRUE. If there are arguments and common block variables of type LOGICAL that must be shared between the two halves of the program, your "substantial bridge" is going to have the devil's own time trying to tell them apart. >> 3. resolve name conflicts at load time caused by different routines >> being loaded from different libraries with the same name but >> different functions, > >This clearly doesn't have _anything_ to do with the subject we are >discussing. This problem can arise even if all the libraries and >main codes are writen in the _same_ language and for the _same_ >implementation. You misunderstood. The situation I described can arise within the same implementation when modules are used, but modules are not a part of pre-1990 standard Fortran, which is what we have been discussing. One of my examples was Fortran 77; the other was Fortran 66. There is no mechanism in Fortran without modules for a user even to force multiple routines by the same name to be loaded; normally the first one encountered is the only one loaded and all others are skipped. The problem also does not arise with runtime support routines in a standard-conforming implementation, because the implementor has full control over the namespace. Runtime support routines typically have nonalphabetic characters in their names in order to prevent collisions with the user namespace. When you mix two versions of Fortran, strange, new things can happen. Compiler A may have a runtime support routine $FOO whose purpose is to implement the ** operator for REAL operands. Compiler B may have a runtime support routine $FOO that repositions direct access files. When you mix routines that were compiled by both compilers, you are asking a lot of a loader that was designed without modules in mind to get both routines loaded and correctly associated with the calls appearing in both halves of the program. A user's program may have no visible references to "FOO" or "$FOO", but it still needs two different versions of the routine. I would mention the fact that compiler A has a different routine $BAR for repositioning direct access files, and that the two direct access routines will confuse each other if they operate on the same file, but you say you are not trying to support both I/O systems. Therefore, I won't mention it. >However, if you want to discuss this topic, I have a solution to propose. >Add 'module' support to your languages (as from Modula). And I suppose you think adding modules to an implementation that was designed without modules in mind will not take man-years of reprogramming? -- Dave Seaman ags@seaman.cc.purdue.edu
buckland@cheddar.ucs.ubc.ca (Tony Buckland) (08/29/90)
In article <13393@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: > ... Beyond the requirement that LOGICAL variables take the >same amount of storage as INTEGER and REAL variables, the standard >places no restrictions on the internal representation and there is >no single "best" way to implement the type. For example, one >implementation may focus on the least significant bit, using 0 for >.FALSE. and 1 for .TRUE. Another may focus instead on the sign >bit, using +1 for .FALSE. and -1 for .TRUE. ... The universal convention, so far as I know, is that .FALSE. is always represented by all bits zero, while *any* bit on must be recognized as .TRUE. and detected by the code generated by a conforming compiler. Switching must always be done by moving a full word (or whatever) of zero bits into a variable to set it .FALSE., or a full word or whatever containing at least one one bit to set it .TRUE., never by clever bit flipping.
jlg@lanl.gov (Jim Giles) (08/29/90)
From article <13393@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > [...] > I can understand wanting > to call Fortran routines from a Pascal program, but what is the > point in trying to call one Fortran from another, especially when > they are wildly incompatible? Isn't it easier just to recompile > everything using a single compiler? If you have that attitude, you must have had better luck converting code between compilers than I have. Even compiler which are _meant_ to have the same functionality often don't. On the Cray, switching between CFT and CFT77 is not a simple task. It is useful to do this conversion in an evolutionary way - changing a few routines or sets of routines at a time and linking the results together. Further, two different implementations may provide different extensions. I may want to have access to those extensions of _both_ from within a single program. > [...] > My point in introducing the two-incompatible-Fortran examples was > that you can't solve all the incompatibility problems by requiring > all languages to be compatible with the vendor-supplied Fortran on > the machine, [...] I didn't recomment that. In fact, I think it would be silly to require all languages to be compatible with the vendor. After all, what if the vendor implementation was _really_ bad? I said that new implementations should have the _option_ of producing compatible _calls_ if the user chooses. > [...] because there may be more than one vendor-supplied > Fortran, and they may be incompatible. [...] This looks like time to point out the user's option of staying away from the products of such inconsiderate vendors. Even so, new implementations could simply produce the _two_ options - one for each vendor implementation. > [...] Beyond the requirement that LOGICAL variables take the > same amount of storage as INTEGER and REAL variables, the standard > places no restrictions on the internal representation and there is > no single "best" way to implement the type. [...] You are still hung-up on the "all or nothing" syndrome. If logicals are different on two implementations, the bridges will have to alter the values on the way through. But, even without such sophistication, codes which don't pass logical parameters could still be shared. This is a significant number of codes. The issue of compatibility between languages/implementations is obviously not either/or. Clearly, the less compatible two implementations are, the less the user of one will be likely to want to switch to or share code with the other. If a new implementation is incompatible with an old one, then the vendor of the new product obviously doesn't want or need the business of users who already have the older implementation. However, this discussion was originally about language _design_ not implementation. If a new _language_ is fundamentally incompatible with the popular old ones - regardless of how either are implemented - then the designer of the new must really think that users of the old will _never_ be temped to switch: so he didn't bother thinking about them. > [...] > You misunderstood. The situation I described can arise within the > same implementation when modules are used, but modules are not a > part of pre-1990 standard Fortran, which is what we have been > discussing. One of my examples was Fortran 77; the other was > Fortran 66. > > There is no mechanism in Fortran without modules for a user even > to force multiple routines by the same name to be loaded; [...] Nonsense. We have done just exactly that for years. Modules are a mechanism for defining the scope of global data items (common blocks, and subroutines in Fortran). As such, they are completely implementable in the _loader_ (after all, that's the only tool that implements the scope rules of globals). So, make your library builder so that it can tag libraries (or subsets of libraries) as modules. The scope and referencing of these modules can then be given at load time through loader directives. To be sure, this is less convenient than having the scoping described explicitly in the source code - but it has the same capability. Note: the CTSS Cray loader has been able to do some of this for many years. Long before Modula (or various modular Pascals for that matter), I recommended that the full equivalent of modules be put into out loader. Multiple routines with the same name have been possible in our loader since before I came to the lab. > [...] >>However, if you want to discuss this topic, I have a solution to propose. >>Add 'module' support to your languages (as from Modula). > > And I suppose you think adding modules to an implementation that > was designed without modules in mind will not take man-years of > reprogramming? Not for the _users_. Implementors, on the other hand, would have a valuable product on their hands if they did this - so they shouldn't grudge the man-years either. By the way, putting it into the loader - even a loader _much_ more powerful and sophisticated than is usual for UNIX - is about _one_ man year. I know - I provide local site support for the CTSS Cray loader and that is my estimate of the effort to install the feature here. We already _have_ the capability to load routines with duplicate names and link them to their proper calls. J. Giles
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (08/29/90)
In article <13393@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: > [different FORTRANs may represent LOGICAL values differently on the same > machine] In article <9317@ubc-cs.UUCP>, buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes: > The universal convention, so far as I know, is that .FALSE. is > always represented by all bits zero, while *any* bit on must be > recognized as .TRUE. and detected by the code generated by a > conforming compiler. Universal? The machine I did my first real programming on took "any odd number" as .true., "any even number" as .false. Another compiler I used later took "any negative number" as .true., "any non-negative number" as .false., while another language on that machine used exactly the opposite convention. What's more, I've just been reading the book Programming Parallel Processors, ed. Robert G. Babb II The date of the book is 1988, but most of the chapters seem to have been produced in 1986. Let me quote from the CRAY appendix: ... alternate return labels may not be used because CIVIC and CFT pass statement labels in different ways that are totally incompatible ... LOGICAL functions and values are not used because CIVIC and CFT ***use different values for .TRUE.***. -- You can lie with statistics ... but not to a statistician.
cunniff@hpfcso.HP.COM (Ross Cunniff) (08/29/90)
>> ... Beyond the requirement that LOGICAL variables take the >>same amount of storage as INTEGER and REAL variables, the standard >>places no restrictions on the internal representation and there is >>no single "best" way to implement the type. For example, one >>implementation may focus on the least significant bit, using 0 for >>.FALSE. and 1 for .TRUE. Another may focus instead on the sign >>bit, using +1 for .FALSE. and -1 for .TRUE. ... > > The universal convention, so far as I know, is that .FALSE. is > always represented by all bits zero, while *any* bit on must be > recognized as .TRUE. and detected by the code generated by a > conforming compiler. Switching must always be done by moving a > full word (or whatever) of zero bits into a variable to set it > .FALSE., or a full word or whatever containing at least one one > bit to set it .TRUE., never by clever bit flipping. Well, no. Take the following code fragment: logical l integer i equivalence (l,i) i = 2 print *, l end This results in the following output: T (HP9000 Series 300 workstation) F (HP3000 minicomputer) F (DEC VAX) Most UN*X compilers apply the same rule you quoted; however, there are quite a few non-UN*X compilers out there. Lest you think that, just because this is not a standard conforming program, there is no problem, consider the fact that most UN*X compilers have an option to treat logicals as the VAX does... Ross Cunniff Hewlett-Packard Colorado Language Lab cunniff@hpfcla.hp.com
ags@seaman.cc.purdue.edu (Dave Seaman) (08/29/90)
In article <61409@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [Re: recompiling instead of building bridges] >If you have that attitude, you must have had better luck converting >code between compilers than I have. Even compiler which are _meant_ >to have the same functionality often don't. On the Cray, switching >between CFT and CFT77 is not a simple task. It is useful to do this >conversion in an evolutionary way - changing a few routines or sets >of routines at a time and linking the results together. I have spent a fair amount of time converting Fortran codes between compilers, sometimes on the same machine, sometimes on different machines. I did not say it was easy. I suggested that it is easier than building "substantial bridges". What happens when your machine is eventually replaced, and your "substantial bridge" goes with it? >> There is no mechanism in Fortran without modules for a user even >> to force multiple routines by the same name to be loaded; [...] > >Nonsense. We have done just exactly that for years. Modules are >a mechanism for defining the scope of global data items (common blocks, >and subroutines in Fortran). As such, they are completely implementable >in the _loader_ (after all, that's the only tool that implements the >scope rules of globals). My mistake. I meant to say, "no mechanism in STANDARD Fortran." I have been noticing for some time that you always exclude extensions when they are inconvenient for your position, but you are quick to include them when you see an advantage. You even ruled out extensions earlier in this thread, when you thought I might be about mention some. -- Dave Seaman ags@seaman.cc.purdue.edu
jlg@lanl.gov (Jim Giles) (08/30/90)
From article <13441@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman): > [...] > My mistake. I meant to say, "no mechanism in STANDARD Fortran." Yes, but what you _did_ say was "no mechanism" - period. > [...] I have been > noticing for some time that you always exclude extensions when they are > inconvenient for your position, but you are quick to include them when you > see an advantage. You even ruled out extensions earlier in this thread, > when you thought I might be about mention some. That is because I make a distinction between the _definition_ of a language and the _implementation_ of it on a particular machine. I can understand why C proponents can't understand such a distinction - until this January their language didn't _have_ a definition: only a set of implementations. If we are talking about the language _definition_ (as we were previously doing), I would indeed rule out discussion of extensions. As we are presently discussing _implementations_ (and not even of the language), I feel justified in pointing out that implementations exist that that _DON'T_ require language extensions but _DO_ allow the same features as modules provide. I even pointed out _explicitly_ in may last posting that what I was proposing would require modification to the language only for convenience. By the way, I thought it was quite clear in the context of this discussion that we were talking about the implementation of the language environment - not even the languages themselves. It is obvious that calling one language from another is not part of the _definition_ of any existing standardized language (although, it is my contention that maybe it should be for some). It is also clear (and I have pointed it out) that the languages could be extended to provide this capability (modules and giving language attributes to external declarations come to mind). Such changes to the language have a convenience value, but are not necessary. You can achieve the desired result without using the languages themselves in non-standard ways. Indeed, the only extensions that I have excluded from this discussion are attempts to claim that calling between two Fortrans is impossible because they might each have different extended data types. It is not even clear to me the _meaning_ of calling (say) a QUATERNION valued function from a Fortran that doesn't have quaternions. This is true of any mixed language calls - you can't expect to pass arguments or results with types that one of the languages doesn't have. (Even in this case though, the ability to call between languages can be exploited by the user. A _user_ written bridge (in addition to any automatic one) could provide a means for the languages to communicate values of the unusual data types. For example, QUATERNION could be represented as an array of 4 reals. But, the user can't do this unless he first has the ability to call between the languages using the data types that they both share.) Calls between languages using data types that they both share is obviously possible. It can be done automatically - even when the internal represen- tations differ. The loader (or some pre- or post-loader tool) knows what language each routine is written in, it _can_ know the internal represen- tations of all the data types in each language, it knows the types of arguments and of function results, it can therefore automatically bridge. There are probably more efficient ways of doing this conversion, but this is at least possible. It also points out the negative value of gratuitous differences between languages and implementations - the fewer and simpler the differences in internal representations, the simpler the process of building a bridge. Finally, as I keep pointing out, this is not an either/or issue. _ANY_ ability of two languages or implementations to communicate with each other is probably an advantage to both. The more fluently and flexibly they can call one another the better. J. Giles