Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa Path: utzoo!linus!decvax!bellcore!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.lang Subject: Re: and if you put this in your languag Message-ID: <800011@ccvaxa> Date: Wed, 2-Apr-86 10:57:00 EST Article-I.D.: ccvaxa.800011 Posted: Wed Apr 2 10:57:00 1986 Date-Received: Sat, 5-Apr-86 05:44:53 EST References: <1187@mmintl.UUCP> Lines: 46 Nf-ID: #R:mmintl.UUCP:1187:ccvaxa:800011:000:2294 Nf-From: ccvaxa.UUCP!aglew Apr 2 09:57:00 1986 >/* Written 11:12 am Mar 25, 1986 by db@cstvax.UUCP in ccvaxa:net.lang */ >In article <6843@boring.UUCP> lambert@boring.UUCP (Lambert Meertens) writes: >>In article <800009@ccvaxa> aglew@ccvaxa.UUCP writes: >>> but if Z is not simply a function call then you have to make sure that two >>> copies of code get updated. That's what macros are for [...] >> >>Some languages have "refinements", which are somewhat like macros but they >>really are part of the language and do not get expanded by a preprocessor. > >Isn't it simpler to have a parameterless procedure with no local variables >and a compiler that recognises such things? Maybe with pragmas giving the >user control over the optimisation if you want it? True in principal, but the problems are conceptual as well as implementation. Z may depend on a lot of the environment in which it is called, so a parameterless procedure will not work unless you have dynamic binding. Dynamic binding has a whole slew of other problems, not the least of which is efficiency; however, probably the most important one is that programmers make more bugs in dynamic binding systems (no source for this statement) Properly parametrizing a Z procedure is a pain. People don't handle more than 5 independent parameters well. If you read the article about Knowledge-Based Emacs in SIGPLAN(?) a while back, you've encountered `cliches' - I think that cliches are simply (macro) procedures with an inconveniently large number of parameters. >Procedures handle sequential abstraction fine. Want you seem to be after >is greater control over the way they're implemented. You don't have to >allocate a new frame on the stack just because you call a procedure, if >there is nothing to put in it! > >Maybe I've spent too long programming in functional languages, where you >have to do things like this (and tail recursion optimisation similarly) >to get decent performance. Is my big problem with functional languages - they may be better for expressing higher-level algorithms, but what good are they if I have to tie myself in knots for what I already know how to do. > > Dave Berry. CS postgrad, Univ. of Edinburgh > ...mcvax!ukc!cstvax!db Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ...!ihnp4!uiucdcs!ccvaxa!aglew ARPAnet: aglew@gswd-vms