Xref: utzoo comp.arch:20880 comp.lang.misc:6627 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!nigel.ee.udel.edu!mccalpin From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Computers for users not programmers Message-ID: Date: 15 Feb 91 16:16:26 GMT References: <3159:Feb1213:56:3091@kramden.acf.nyu.edu> <1991Feb12.192725.21029@Think.COM> <1087@kaos.MATH.UCLA.EDU> <1991Feb15.151910.5365@ux1.cso.uiuc.edu> Sender: usenet@ee.udel.edu Followup-To: comp.arch Organization: College of Marine Studies, U. Del. Lines: 55 Nntp-Posting-Host: perelandra.cms.udel.edu In-reply-to: mcdonald@aries.scs.uiuc.edu's message of 15 Feb 91 15:19:10 GMT >On 15 Feb 91 15:19:10 GMT, mcdonald@aries.scs.uiuc.edu (Doug McDonald) said: Doug> In article khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >A major reason for adding operator overloading and modules is to >permit such things to be defined apart from the language itself >(possibly by folks with specialized needs). > >In comp.lang.fortran there has been some discussion of what should >folks start thinking about working on "next" ("fortran90" looking >likely to be an ISO standard before the end of the year). A very >reasonable thing would be a standard module for entertaining >mathematical problems such as this. Doug> Mr. Bierman apparently misunderstands: these thinsg will do NO GOOD Doug> if they are implemented as "modules" written into the old language Doug> which is missing them: if somebody does that, they CAN'T use the Doug> special machine constructs that would make them fast. [....] This was one of the points that was addressed in the Algol-68 concept of standard packages. The idea was that several commonly used modules would be standardized as part of the language. They could be defined in terms of the language, which would provided instant portability, but might also suffer in performance (as McDonald points out above). The key, of course, is that the modules are "standard", so that there exists some incentive for the vendors to produce optimized versions, which presumably could make use of any hardware or software tricks that are available. An analogy would be to require the level 1,2,3 BLAS (Basic Linear Algebra Subroutines) to be a part of a standard-conforming Fortran implementation. They can be ported almost instantly by simply compiling the Fortran source, or they can be as carefully optimized as the vendor desires. The discussion in comp.lang.fortran is based on the idea that if certain modules come to be in very widespread use, then it might be appropriate to request that that functionality be included in the next revision of the base language. In fact, the process does not need to be so formal. If the modules are actually in such widespread use, then buyers will simply make use of such modules in their qualification benchmarks and the vendors will quickly respond by providing optimized versions. This is beginning to happen with the Level-3 BLAS and the LAPACK project even though such libraries do not fit into the language as easily as modules. I expect that a 'module' version of LAPACK will be written very shortly after Fortran Extended becomes available and that it will be immensely popular. -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET