Xref: utzoo comp.arch:20875 comp.lang.misc:6624 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!news From: mcdonald@aries.scs.uiuc.edu (Doug McDonald) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Computers for users not programmers Message-ID: <1991Feb15.151910.5365@ux1.cso.uiuc.edu> Date: 15 Feb 91 15:19:10 GMT References: <3159:Feb1213:56:3091@kramden.acf.nyu.edu> <1991Feb12.192725.21029@Think.COM> <1087@kaos.MATH.UCLA.EDU> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 29 In article khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >.... >> Until such primitive operations are added to our languages, > >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. > Mr. Bierman apparently misunderstands: these thinsg will do NO GOOD if they are implemented as "modules" written into the old language which is missing them: if somebody does that, they CAN'T use the special machine constructs that would make them fast. They COULD of course be written as functions in assembler, if there happens to be some reasonably fast way of getting the data in and out in function form. Anything CAN be written in C - but it might not be fast enough to be useful. Doug McDonald