Xref: utzoo comp.lang.lisp:4529 comp.lang.scheme:2008 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: <1991Feb28.051911.846@Think.COM> Date: 28 Feb 91 05:19:11 GMT References: <4234@skye.ed.ac.uk> <8768@castle.ed.ac.uk> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 57 In article <8768@castle.ed.ac.uk> jeff@castle.ed.ac.uk (Jeff Dalton) writes: >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: > >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. Quite true. The most notable difference between Maclisp and Common Lisp in this regard is the first-class standing given to many of these packages. In Maclisp, one had to load lots of optional libraries to get these facilities; consequently, the Maclisp manual was much smaller than the Common Lisp manual. The problem was that there were sometimes more than one version of some of the facilities (Bernie Greenberg did a DEFVAR for Multics Emacs, but its syntax was (defvar (var1 init1 doc1) ... (varN initN docN))). Common Lisp incorporates most of the popular facilities, so that users would be able to port their programs without having to copy all these auxiliary libraries. >>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. I just wanted to mention that my original comment about realizing that EVAL isn't fundamental to Lisp-like languages, was based on my previous belief in the above statement about "reasoning" about programs. If the lambda calculus was designed to allow reasoning about algorithms, and Lisp was intended to be a realization of the lambda calculus, then it seemed that Lisp should be able to reason about itself. Further, many AI researchers thought Lisp was appropriate for machine learning, because learning could be implemented by rewriting programs. However, I don't think the original Lisp had EVAL. Recall that Lisp was originally a Fortran library for symbolic manipulation of data structures. All it had was conses, symbols, and numbers. Lambda calculus and predicate calculus could be represented using these structures, but I suspect that the programs that did this treated them abstractly (i.e. to write theorem provers). At some point one of McCarthy's students realized that an *executable* program could be represented using the same data structures as lambda calculus, and wrote EVAL, which allowed the interactive Lisp interpreter to be written. While EVAL is important to the Lisp family of languages, it seems that symbolic manipulation is more fundamental. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar