Xref: utzoo comp.lang.lisp:4516 comp.lang.scheme:1998 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Scheme as an Algol-like, not Lisp-like, language Message-ID: Date: 26 Feb 91 19:49:09 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <4234@skye.ed.ac.uk> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 138 Nntp-Posting-Host: odin In-reply-to: jeff@aiai.ed.ac.uk's message of 25 Feb 91 15:12:05 GMT X-Old-Subject: Re: Memory Management in Lisp? On 25 Feb 91 15:12:05 GMT, jeff@aiai.ed.ac.uk (Jeff Dalton) said: jeff> In article jeff> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: barmar> Traditionally, one of the most important differences between barmar> Lisp and most other languages has been the fact that memory barmar> management is automatic. pcg> Unfortunately this has traditionally encouraged sloppiness. 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. 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!). 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. 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 :-). 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. pcg> Also, Scheme is not a Lisp -- it is an Algorithmic Language :-). jeff> Single inheritiance thinking rides again. [Common Lisp is a Lisp but jeff> not supposedly an "Algorithmic language". Scheme is an Algorithmic jeff> language. Since Algorithmic language is not a subcategory of Lisp, jeff> and Lisp is not a subcategory of Algorithmic language (because of jeff> such Lisps as Common Lisp), it must be that Scheme is not a Lisp.] Now, *you* are underestimating me a bit. The serious point I was making is that a Lisp is historically a symbolic List Processing language, while, except for the survival of 'cons', 'car', and 'cdr', Scheme is more of something in the Algol 60 tradition, with a superficially Lisp-like syntax. Unfrotunately I was not using, mea culpa, Algorithmic Language in the proper sense of alternative to Programming Language, but in the narrower and less proper sense of Algol like language. Scheme is an Algorithmic Language that is Algol-like, while there are non Algol-like algorithmic languages (e.g. APL, or ML); CommonLisp is a Programming Language that is Lisp-like (in a cancerous way :->), while there are Lisp-like languages that are not programming languages (the old UW or Vincennes Lisps, Forth and TRAC (TM) maybe qualify as Lisp-like too). The lack of an explicit 'eval' gives the show away, I am afraid (just like the consequence of having 'quasiquote' & Company as primitives does). Scheme cannot be used, portably, to "reason" about programs, inasmuch it cannot *directly* build and execute *program fragments*, like every Lisp-like language is supposed to do. Some say this is *the* distinguishing characteristic of Lisp-like languages, however rarely it is used in practice. Scheme can "reason" more powerfully than most other languages (including Common Lisp), thanks to lexical closures and to continuations, and to explicit environments supported by many implementations, about *program states*, in both the context and the control graph, but this really is in the Algol-like language tradition, where 'own' is the root of all such powerful technology. OO technology, which is related to it, is after all a consequence of 'own', of Simula I and Simula 67, all Algol-like languages. The Lisp-like language tradition had to fumble with the upward and downward funarg issue almost forever (until Steele and Baker, more or less), even if as of now funargs are more mainstream in the Lisp-like language camp than in the Algol-like language camp. After all this, IMNHO it is not so far out to say that Scheme is an alternative syntax (modulo the latent type issue) for an Algol 68 subset, if Algol 68 had upward funargs (and some Algol 68 _implementations_ had them, as an extension to the standard!). I think that the provision of *excessive* and *regrettable* (complex and rational!) numeric facilities in Schemeis also designed to give the impression that it is designed to be more of a Algol-like language than a Lisp-like language. It is true however that most Scheme *implementations* have actually been like Lisp implementations, that is workspace based, and with 'eval'; but I am sure that a 'schemec' compiler that generated object code like the 'cc' compiler could be done, and actually some imperfect realizations do exist (scheme2c from DEC actually is mostly used to produce objects to be loaded in a Scheme environment; PreScheme from MIT is better geared, I seem to understand, to generating standalone executables to be linked with a library). Actually, let me say, I think that one of the fatal mistakes in Scheme, like it was for Pascal, is that there is no standard way to address separate compilation! Seriously. Think carefully about the implications... -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk