Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased From: chased@rbbb.Eng.Sun.COM (David Chase) Newsgroups: comp.lang.misc Subject: Re: Fortran, C, or ?? for numerical work Message-ID: <3859@exodus.Eng.Sun.COM> Date: 3 Dec 90 18:48:25 GMT References: <2392:Nov2902:59:0590@kramden.acf.nyu.edu> <7339@lanl.gov> <1990Nov30.163613.9562@alchemy.chem.utoronto.ca> <763@ubbpc.UUCP> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 54 mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: >> wgh@ubbpc.UUCP (William G. Hutchison) said: >> I see at least two solutions: >> (1) Stop doing numerical work [ :-) ] >> (2) Find or develop a language suitable for this sort of work. >... >My interests right now are leaning more toward Modula-3, because of >its support for classes/objects. Unfortunately, Modula-3 fails in the same way that C does with respect to (pulling out a quote that you didn't quote): >> (2) C programmers mostly work on micros, workstations, or minicomputers, >> so they are not acquainted with pipelining, vectorizing, parallel >> processing, etc., so they do not know what they are missing by using C. These optimizations apply about equally well (poorly) to C and Modula-3. The reason, barring whole-program optimization (interesting in a land of pointers-to-procedures, too) is that Fortran has its weird little parameters-are-not-aliased rule, and C and Modula-3 do not. It's a little easier to mandate not-aliased in a language without recursive data structures (i.e., pointers) like Fortran; in C/Modula-3/others, such a rule seems oddly stunted and special-case. For example, consider "f(LIST p, LIST q), p notalias q". Speaking Fortran, that means that the heads of the lists are not aliased, but who knows about the rest? One might, perhaps, say something along the lines of either p(.cdr)* notalias q(.cdr)* (default is aliased) or p(.cdr)* mayalias q(.cdr)* (default is not-aliased) to specify that the heads and the spines of the lists are not / may be aliased. (and what do I mean by not aliased? For each run-time call, taking the instersection of the two sets p(.cdr)* and q(.cdr)* should yield the empty set, and mangle what I said to turn it into sets of pointers to things.) Anyhow, perhaps this explains why these rules have not been adopted in other languages (yet). All the solutions I come up with in a couple of minutes appear weird, ad hoc, and non-general. Non-aliasing mandates have good effect on remote implementations of things (RPC), too, which is another reason to like them even if you hate heavy-duty optimizations. I'd have to go read more about this stuff to get a handle on what is good, bad, and ugly -- unless the FX-87 people want to get into a discussion about their work (much of which remains unread by me, unfortunately). It helps to keep the constraints of checking and inference in mind, also -- closure properties of regular languages are very useful, for instance. David Brought to you by Super Global Mega Corp .com