Path: utzoo!attcan!uunet!mailrus!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.society.futures Subject: Re: C's sins of commission (was: (pssst...fortran?)) Message-ID: Date: 1 Oct 90 14:47:19 GMT References: <9009202236.AA21344@raven.pa.dec.com> <63647@lanl.gov> <5006@uqcspe.cs.uq.oz.au> <5049@uqcspe.cs.uq.oz.au> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 38 In article <5049@uqcspe.cs.uq.oz.au> brendan@batserver.cs.uq.oz.au writes: > But seriously folks what you really want is a procedure. Note that this > function (which makes explicit the action of the of the operation) > cannot (easily) be used as an integer term, and must be accompanied with > an update to seed for the whole thing to work properly. Precisely. > rnd is not an > integer term, its purpose is not solely to define the value of an > integer. Why then do you want to include rnd in the grammar of integer > terms? Why do you assume that the algebra you find useful for the basis of a programming language is the same algebra that I find useful for the basis of a programming language? > Is it just to save a few keystrokes in the initial coding? Pretty > silly given that this is such a small part of the software cycle. The > idea is not conciseness but clarity! Suppose one is implementing an algorithm taken from the literature. Would it not be clearer to use the same syntax as that in the source document? (this is beginning to sound like the famous GOTO debates. If so, GOTO alt.flame). Suppose one is working with a database library, then. How about the following code: struc3 = join(struc1, struc2, key_info); This the clearest way of expressing this, yet join() modifies all sorts of global state. Even if struc1 and struc2 are local, the new struc3 has to be allocated... now you're modifying the heap. If the structs are in external files you've done lots of global operations to read and write parts of the files. Yet it is desirable to implement the database library with this sort of interface... it's clearer. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com