Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!ut-sally!seismo!gatech!akgua!whuxlm!whuxl!houxm!hropus!riccb!ihopa!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <13400021@ccvaxa> Date: Fri, 27-Jun-86 11:54:00 EDT Article-I.D.: ccvaxa.13400021 Posted: Fri Jun 27 11:54:00 1986 Date-Received: Mon, 30-Jun-86 03:36:31 EDT References: <1311@well.UUCP> Lines: 89 Nf-ID: #R:well.UUCP:1311:ccvaxa:13400021:000:4376 Nf-From: ccvaxa.UUCP!preece Jun 27 10:54:00 1986 > Jeff Jacobs writes: > As an oversimplified definition; development environment is interpreted > with dynamic scoping (lexical scoping is a compiler optimization), no > distinction between executed code and data unless specifically compiled > (i.e. not incrementally compiled), no required keywords and pre-CL > function definitions (such as MEMBER). Examples include MACLISP, > INTERLISP, FRANZ and UCI. ---------- I have to agree with Hedrick and Shebs and one of the primary philosophies of CL -- the compiled environment and the interpreted environment should behave the same way to the greatest extent possible. The notion of dynamic scoping turning into lexical at compilation is appalling. On the other hand, I'm not completely pleased with the CL approach, either. There are times when scoping doesn't do what those of us coming from the non-Lisp side would expect. ---------- > It's not a matter of "broken", it's a matter of incomplete. How much > time, effort and money will it take before a "complete" implementation > that doesn't derive from SPICE will appear? ---------- Isn't Lucid sui generis? Franz Common claims to be, but I gather you consider it to be broken (I haven't used it). ---------- > Unfortunately this isn't written in the proper style of a standard, > and I don't think I should have to read 5 pages to find what should be > clearly and simply stated under the function definition. ---------- There's plenty of discussion on the CL mailing list about problems with the document, but it's not all that bad. A document specifying the complete details of each function (and therefore repeating tons of material common do other functions doing related things) would have been MUCH bigger. Such a thing would be useful, God knows, but for a first statement of the principles and contents of the language, CLtL is much preferable. A more tutorial approach would not have been as effective either. I agree with your complaint about the fonts used for non-text material. Personally, I would have preferred a non-monospaced font and something denser (thus standing out better). I certainly would NOT have supported use of upper-case, which is fine for occasional emphasis but much less readable. ---------- > If you spend 10 years using SETQ thing it's the same as (SET > (QUOTE)... or MEMBER is different from MEMQ, and suddenly it all > changes, you're gonna be damned unhappy. > Fine. I don't agree, but DON'T CALL IT MEMBER!! Call it something > else and if you want to add funky syntax and make it a special form, be > my guest. But don't kill my working code that goes back many years!!!! > And don't invalidate all of the text books, articles, etc that have > already been written and used for many years! ---------- Well, yes and no. You can't do a derivative language with new features without changing the meaning of some of the existing constructs. It's vital, of course, that you point things out sufficiently clearly that the careful reader (anyone who skims this kind of document gets exactly what she deserves) can take note of what has changed. The book is reasonably careful about giving explicit notice about such functions (which your original posting actually complained about). MEMBER, by the way, does not default to EQ testing, it defaults to EQL testing. It should not be a big deal to make that kind of change in existing code -- just change the name of the function in your existing code and provide a macro supporting your name in terms of the underlying CL primitive (I'm sure that kind of change is second nature to you anyway, given the kind of Lisp background you have). The number one goal of CL was to provide a common base for new Lisp development. It seems to be the case that the world of AI vendors has bought that goal -- everybody seems to be building versions of CL, even Xerox. Nobody would expect the first version of something as big as CL to be definitive, but conforming implementations should be close enough that porting will be much easier than in the past. Experience should indicate the specific areas that need further work in specifying a formal standard (an effort now under way) and moving towards common understanding of the issues that were insufficiently specified in CLtL. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms