Xref: utzoo comp.lang.lisp:4524 comp.lang.scheme:2004 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!jeff From: jeff@castle.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: <8761@castle.ed.ac.uk> Date: 27 Feb 91 15:53:23 GMT References: <4234@skye.ed.ac.uk> Organization: Edinburgh University Lines: 98 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >jeff> More often automatic storage management makes it easier to write >jeff> code that is clearer and in a sense more abstract. > >Mostly agreed, but clearer and more abstract code should be modularized >so that explicit storage reclamation can be slipped in easily. When this >cannot be done, one has a tradeoff between having it easier to write >code that is slightly clearer and more abstract and using a machine >which costs ten time less, and the choice is often loaded :-). We all >already know this, but I'd like to emphasize it. I would disagree that the code is only "slightly clearer" and that the machine would cost 10 times less. Let's suppose Lisp is a factor of 2 slower due to garbage collection, which in some cases is an overestimate. I bought a 386 machine a few months ago, and now for more or less the same price I could get a 486 that's twice as fast. So it looks like I could get my clearer and more abstract code without paying anything more. This estimate is no doubt off, but I don't think it's off by a factor of 10. Of course, if someone came up with a language in which I could slip in explicit storage management (1) without having to write more awkward code in order to allow the slipping-in and (2) without having slower automatic storage management, I would be happy to use it. >jeff> A number of Lisp hackers _did_ think about garbage generation >jeff> rates when it was appropriate to do so. > >Ah yes, they did, the good ones and those with vast experience and >serious problems, but not everybody is a Dalton or Margolin, and garbage >generation rates are not even mentioned, just like locality of reference >in C/Unix books, in any Lisp/Scheme book I have seen -- please don't >post counterexamples! Every gross generalization like this has them, but >I hope you get the message, which is garbage generation rates is not >thought to be an issue worth mentioning, while for example time, but not >space, complexity is often prominently addressed (entire books devoted >to it!). Although books clearly have some impact on programming practice, I don't think they necessarily give a true picture of what that practice is. Since you won't let me use counterexamples, let me reply with some gross generalizations. Almost all Lisps texts are introductions and consequently treat efficicency as a relatively minor concern. It might be argued that they're wrong to do this, but I think it's understandable. Experienced programmers think differently, and many User Manuals for implementations discuss efficiency at length in recognition of this. >Even research in these issues has become unfashionable, like research in >locality of reference, and I can think of precious few contributions in >either field for the past ten years or so. I will leave this to people who have a stock of references nearer to hand. There are certainly things I've heard about only in the last 10 years, but of course that's not the same thing. >barmar> Even EVAL isn't as fundamental to Lisp as I once thought, since >barmar> Scheme doesn't have it [ ... ] >pcf> The entire Scheme report is really about defining the semantics of >pcg> 'eval'. >jeff> I hope you're not supposing that Barmar didn't know this. > >Your hope is well founded. I do occasionally restate the obvious just to >make is clearer what is the shape of my reasoning, if any, and not null >and void where prohibited by relevant statutes :-). Yes, but I think you end up addressing the wrong point. Barmar was clearly talking about a sense of "have EVAL" in which Lisp normally has it but Scheme does not. All Lisps, including Scheme, define the semantics of 'eval'. So I would say Barmar must be talking about something else, namely that Scheme does not make eval available as a function. Since this is a well-known and much-discussed issue, Bamar didn't need to state it explicitly in order to make his meaning clear. Or so I would have thought. >pcg> It does not have a way to invoke recursively the 'eval', but >pcg> that is probably best left as an implementation issue. > >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. > >Well, my reasoning goes as follows: the Scheme RR defines the semantics >of 'eval', but does not define how to *invoke* it, because invoking it >*is* an implementation dependent issue. It may be something like 'scheme >', for example, in most implementations. Or the implementation may >be a Scheme machine and all you have to type is '', 'eval' being >implicit. Well, all that is true, but it is still not what Barmar was talking about. I will leave the "Scheme isn't a Lisp" for another message while I go look for a better editor on this random machine I'm using (the usual one being broken). -- jeff