Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines From: jonl@lucid.COM (Jon L White) Newsgroups: comp.lang.scheme Subject: To Lisp, or not to Lisp; that is the question. Message-ID: <9103080432.AA06368@kolyma> Date: 8 Mar 91 04:32:45 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 128 I've been most amused by the argumentations recently about why Scheme should be considered a descendent of Algol-60 and not of Lisp. Clearly, some recent converts to the fold really haven't grasped what Lisp is all about, and would probably even have great difficulty mounting a credible attack on the thesis that "C is dialect of Lisp". First off, I appreciated Jinx's listing of "interesting", typical attributes of Lisp dialects: Date: 27 Feb 91 02:30:28 GMT From: "Guillermo J. Rozas" Well, what makes a Lisp? Let me suggest a few requirements. 1. List processing. 2. Programs that look like data. 3. Objects with unbounded extent and automatic storage management. 4. EVAL (making use of 2). 5. Powerful syntactic extension facilities that make use of 2. 6. Call by value. 7. Imperative constructs. 8. Functional style encouraged, or at least not discouraged. 9. Latent types. 10. Generic arithmetic, with integers not restricted to the word size of the machine. 11. Interactive development enviroments. but I too would have added: 0. incremental "on-the-fly" definition and re-definition capabilities To some of us, this has long been a dominating characteristic up there along AutomaticStorage (GC), Macros (in the same language!) and the big seven: CAR, CDR, CONS, ATOM, EQ, QUOTE, and LAMBDA. Of course, it may be difficult to see how to effect Jinx's item 4 without this kind of incrementality; but as subsequent discussion about the programmability of EVAL in terms of documented primitives shows, the existence of an interpreter can't be fundamental. Gosh, there even exist interpreters for the infamous Machine-Independent Machine Language (you know, the language that comes bundled in with most Unixes, and that is generally known by a one-letter acronym beginning with C.) Indeed, the messages about the environmental difficulties of LOAD strike right to the heart. Do you know of any conventional computer language in which the compiler's symbol table is not only present in the runtime image, but it is effectively a first-class data object? (and I DON'T mean "environments" -- I mean symbols). So, I would say, if you wan't to keep Scheme in the Lisp family, don't break LOAD by turning it into INCLUDE. The trouble with explicit listings of features, however, is that there will always exist some Lisp out there somewhere that will lack, or violate, any given feature. That is as it should be. In a nutshell, Lisp comes from the "ball of mud" family, whereas many recent languages are of the "crystalline gem" variety. What's the difference? Well, the most enduring purpose to which Lisps have been put is in the experimentation with new ideas in programming languages. What, you don't like the slowness of latent types (runtime type markers and dispatches)? then simply stick a DECLARE statement taken directly out of FORTRAN II into the language and make it work like Fortran; now you have a language that is _both_ latenly typed and statically typed, with the advantages (and somtimes the detriments) of both. What, you don't like full stack retention just for making a simple parametric function? then add in the rule of "closure'ing" only over the lexically apparent variables, and you have a lexically scoped Lisp as well! [well, in truth, as George Carrette pointed out, MacLisp was, and Common Lisp is, both dynamically scoped and lexically scoped for most intents and purposes; but it is really only for the semantics of first- class functions -- "closures" where the difference matters in a big way.] What, you have a 640K PC, and find that you can't even load the 11MB image that your compiled "hello world" application turns into? then just add a DEFSYSTEM-like facility and call the TREESHAKER to turn it into a 300KB image ("TREESHAKER" == a garbage collection from "real" roots; just grab your application by it's roots and shake very hard so that all of the unattached pieces fall off. Maybe the "defsystem" has to do a little pruning of the tree first.) So. Flexibility. The Artist's "ball of mud" which is plastic in his hands, to be pushed and molded in any direction profitable; which retains its essential malleable character no matter how badly deformed; stomp on it here, and it Lisp pops its head up over there. But what about the conventional languages? take that "diamond" of a language, Algol; it's beautiful, it's perfect! but touch it's design in any way and it immediately shatters into a million little pieces. Change just one tittle of your C code on just one line somewhere -- and it's forget it Charlie, have to re Make the world all over again, Big-Bang de-novo. Or, just try to throw Garbage Collection into your basic fragile "strongly-typed" computer language, where datatypes are only a dream in the mind of the compiler, and watch your address space silt-up with the orphans of "conservative" or heuristic reclamation approaches. [Proponents of pure "statically-typed" languages don't always have a consistent reason as to why they reject the very minor modifications necessary to make _accurate_ GC possible in their language; but there are always two ruses they can fall back on: (1) runtime-typing seems involved, and that adds one instruction to some compiled-code sequence somewhere, so the performance would be unaccaptable, or (2) "our language" supports real-time embedded systems -- such as Jet aircraft wing controllers -- and programs must never be side-tracked by an excursion into an unplanned GC. Brittle. Indeed, it was infinitely easier to add Fortran's DECLARE into Lisp -- as my own work with PDP10 MacLisp back in 1971 to 1973 showed -- than it is to add even the simplest of the Lisp characteristics to ADA. And ADA was even planned with the thought of GC in mind!] Anyone for ADA++ ? But one more historical fact places Scheme squarely within the Lisp family. For years, during and after its genesis, its father -- Gerry Sussman -- directly owned up to his paternity and claimed it as one of his own "Lisp" dialects (he had engendered several during the early 1970's). And the mid-wife to its birth -- Guy Steele -- says so too. With such endorsements ... well, if it isn't clearly obvious that Scheme is a dialect of Lisp, then clearly we must extend the meaning of "Lisp" to include it, to adopt this fertile child of the family. To give credit where credit is due, the analogy of Lisp as a "ball of mud" -- because of its ability to absorb the good ideas of other programming languages (e.g, Fortran, ECL, Algol, etc.) -- comes from Professor Joel Moses of MIT. He coined it at a time when MacLisp was being molded to fit the requirements of that symbolic algebra manipulation system which we all know and love as MACSYMA. -- JonL --