Xref: utzoo comp.lang.lisp:4525 comp.lang.scheme:2005 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!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: <8768@castle.ed.ac.uk> Date: 27 Feb 91 17:45:56 GMT References: <4234@skye.ed.ac.uk> Organization: Edinburgh University Lines: 173 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 25 Feb 91 15:12:05 GMT, jeff@aiai.ed.ac.uk (Jeff Dalton) said: >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. 1. Scheme aims to be both a Lisp and an Algol-like language. The former ought to be clear on a variety of grounds. Evidence for the latter includes the name of the TeX style file for the Scheme reports (ie, "algol60"). The idea that Scheme is not a Lisp is promulgated mostly by those who do not like Lisp but want to, somehow, make an exception of Scheme. Due to single-inheritance thinking, they think this ought to be done by placing Scheme outside of Lisp. I would also disagree with the suggestion that Scheme is more an Algol than a Lisp. 2. The idea that Scheme is further away from list processing than other Lisps is somewhat bizarre, because many other Lisps have a greater range of data types than Scheme. Scheme is different from traditional Lisp in large part because it was developed later. Lisp is not now, if it ever was, a language in which "everything is a list". 3. The scheme syntax is not _superficially_ Lisp-like; it is a Lisp syntax. >Unfortunately 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). "Proper sense"? Give me a break. I will agree that you have now departed from single-inheritance, but only to the extent of having two hierarchies instead of one. I do not find your elaborated classification scheme any more convincing. ML is closer to Algol in many ways than Scheme is. Forth and Track may be in some class that also includes Lisp, but there's surely a better name for it than "Lisp-like". Scheme, on the other hand, is a variety of Lisp. (It's often said to be a "dialect" of Lisp, but that may imply too strongly that Lisp is a single language.) Indeed, you have the bizarre notion that "Lisp-like" includes some Lisps (eg, Common) but not others (Scheme). (Or perhaps you just have the bizarre notion that "Lisp-like" is a good name for this category.) The idea that Common Lisp is a cancerous departure from "old VW Lisp" is, moreover, just wrong. The evolution from Lisp 1.5 to the main Lisps of the 70s, MacLisp and InterLisp, was a fairly natural one. Common Lisp is the unification of several successors to Maclisp. It is, clearly, larger than MacLisp, but it is not larger than InterLisp. Moreover, many things that may seem peculiar to Common Lisp (format, defstruct, dotimes, etc) were already used in MacLisp. Some critics of Common Lisp don't want to accept this. They want Common Lisp to be a uniquely bad language. (Incidently, when I talk about "some critics" I do not want to imply that they necessarily include pgc. Maybe they do, but I don't know.) >The lack of an explicit 'eval' gives the show away, I am afraid (just >like the consequence of having 'quasiquote' & Company as primitives >does). What? I'll address eval below, where you elaborate on this point. However, Common Lisp could just as well have quasiquote. It isn't that significant a difference. (I hope you aren't counting it as part of the claim that Scheme cannot be used to "*directly*" build program fragments.) >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. Some say it, but they're wrong. There isn't a single distinguishing feature, and EVAL is not first on my list. But this goes back to the notion that there is a useful category "Lisp-like", characterized (it now seems) by the ability to build and execute program fragments at run time. This way of thinking makes sense only if you escape single- inheritance thinking and let this ability be one characteristic among others (and change the name). >Scheme can$"reason" more powerfully than most other languages (including >Common Lisp-, thanks to lexical closures and to continuatiofs, and to >explicit environments supported by many implementations, about *program >states*, I'd stay away from "supported by many implementations" if I were you, since virtually all implementatins let you directly execute program fragments by calling EVAL and construct them via macros if by nothing else. >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. If you start tracing good ideas back to Algol, virtually every "good" language will be "Algol-like". The principal root of such things in Scheme is the lambda calculus and the first-class status of functions. >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. Most of the programming language world managed to "fumble" with functions, if you want to call it that. Lisp 1.5 had upward funargs. Where it went wrong was in not having lexical scoping. The reason the upward/downward distinction became important was that the downward ones were easier to implement efficiently. >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!). Well, yes, let's confine the type question to parentheses. That way we can treat it as unimportant. And let's try this alternative syntax + some implementations trick more generally. Let's see. Because of the KCL compiler, Common Lisp is demonstrably an alternative syntax for C, plus a library of procedures. And C is very like a subset of Algol68 (or else say the KCL compiler could just as well emit Algol68), so it must be that Common Lisp is an Algol-like language. If anything doesn't quite fit, we can just say "modulo" in parentheses. >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 was MacLisp (more or less) that started the emphasis on having good numeric facilities in Lisp. Common Lisp and Scheme have *fortunately* provided exact rational arithmetic. (N.B. not "exact" in the technical Scheme sense.) Other languages (eg, Haskell) have been influenced by Common Lisp and Scheme. >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). And the same can be done with (surprise!) Common Lisp. The same sort of imperfect realizations already exist, eg KCL. -- jeff