Xref: utzoo comp.lang.lisp:4527 comp.lang.scheme:2006 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!percy!data!kend From: kend@data.UUCP (Ken Dickey) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: <451@data.UUCP> Date: 27 Feb 91 20:30:15 GMT References: <1991Feb15.191259.20090@aero.org> Organization: Microcosm, Beaverton, OR Lines: 91 [WARNING: I have not seen the previous postings. Some brain-dead comments may result]. pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg>On 25 Feb 91 15:12:05 GMT, jeff@aiai.ed.ac.uk (Jeff Dalton) said: AUTOMATIC STORAGE MANAGEMENT: ================================ >jeff> More often automatic storage management makes it easier to write >jeff> code that is clearer and in a sense more abstract. pcg>Mostly agreed, but clearer and more abstract code should be modularized pcg>so that explicit storage reclamation can be slipped in easily. When this pcg>cannot be done, one has a tradeoff between having it easier to write pcg>code that is slightly clearer and more abstract and using a machine pcg>which costs ten time less, and the choice is often loaded :-). This strikes me as very simular to the argument against virtual memory. >jeff> A number of Lisp hackers _did_ think about garbage generation >jeff> rates when it was appropriate to do so. pcg>Ah yes, they did, the good ones and those with vast experience and pcg>serious problems, but not everybody is a Dalton or Margolin, and garbage pcg>generation rates are not even mentioned, just like locality of reference pcg>in C/Unix books, in any Lisp/Scheme book I have seen -- please don't pcg>post counterexamples! Every gross generalization like this has them, but pcg>I hope you get the message, which is garbage generation rates is not pcg>thought to be an issue worth mentioning, while for example time, but not pcg>space, complexity is often prominently addressed (entire books devoted pcg>to it!). I don't ever remember a book on C discussing file sizes, but many Uni# systems have disk usages ~98% full at all times. Perhaps some topics are considered "advanced" for programming language texts? Are you particularly fond of "dumb" storage managers? [I have to tell it everything, even tell it to clean up after itself!]. EVAL: ================================ >jeff> There are programs that can use it and they cannot be written in >jeff> portable Scheme. [ ... ] I don't see how any of this makes it an >jeff> implementation issue. My recollection is that R^NRS defined LOAD. Thus EVAL may be written as a function which writes an expression to a file and LOADs it. pcg>The lack of an explicit 'eval' gives the show away, I am afraid (just pcg>like the consequence of having 'quasiquote' & Company as primitives pcg>does). pcg>Scheme cannot be used, portably, to "reason" about programs, inasmuch it pcg>cannot *directly* build and execute *program fragments*, like every pcg>Lisp-like language is supposed to do. Some say this is *the* pcg>distinguishing characteristic of Lisp-like languages, however rarely it pcg>is used in practice. I find it interesting that you argue for making storage management explicit, yet seem to ignore implementation issues such as linking together applications with minimal runtime systems [which is what EVAL is about--keeping a full runtime because one might have to EVAL anything]. I have never seen a Scheme system without some form of EVAL (although it may be a compiler invocation). As Scheme has READ, one can certainly reason well about programs without using EVAL. Again, however, I know of no Scheme implementation which lacks the ability to "*directly* build and execute *program fragments*". PROGRAMMING ENVIRONMENTS: ================================ pcg>Actually, let me say, I think that one of the fatal mistakes in Scheme, pcg>like it was for Pascal, is that there is no standard way to address pcg>separate compilation! Seriously. Think carefully about the pcg>implications... Now that there is a Scheme Language standard, perhaps the Scheme community will do more work on development environment/invocation standards. Note that other languages have typically failed in this area. pcg>-- pcg>Piercarlo Grandi | INET: pcg@cs.aber.ac.uk ================================ Ken Dickey kend@data.uucp