Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!lll-lcc!well!jjacobs From: jjacobs@well.UUCP (Jeffrey Jacobs) Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <1316@well.UUCP> Date: Sat, 21-Jun-86 17:02:25 EDT Article-I.D.: well.1316 Posted: Sat Jun 21 17:02:25 1986 Date-Received: Mon, 23-Jun-86 03:30:17 EDT References: <1311@well.UUCP> <3827@utah-cs.UUCP> Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Distribution: net Organization: Whole Earth Lectronic Link, Sausalito CA Lines: 337 In <3827@utah-cs.UUCP>, Stanley Shebs responds to my original article, <1311@well.UUCP> jjacobs@well.UUCP... >I don't why I'm bothering to respond to this uninformed flame, but I've got >a few minutes to kill before running off to the compiler conference... >Besides, somebody might read this and suppose that this Jeff Jacobs >knows what he's talking about, which is rarely the case, based on this >limited sample. >I think those who flame about language designs should be forced to >design, implement, and distribute their own language, then listen >while know-nothing second-guessers complain about things they >don't understand to begin with... I certainly appreciate personal attacks like this; they make things so much livelier :-). To make my ignorance perfectly clear, let me state that I have not only been extensively involved in design and distribution of LISP (and other sytems); my experience started in 1971 with UCI LISP. You can find my name along with the other people who really did the work on the front page of the Meehan book. BTW, James Meehan had nothing to do with the original implementations; all he did was edit the book (mostly just reproducing the manuals; he didn't even do much editing). "The New UCI LISP Manual"... It's a bad idea to jump to conclusions about other people's ignorance based on a limited sample, particularly in this medium. (Ad hominem attacks are also considered bad form). >Well gee, I wonder what is "true" Lisp... Let me use the term "Real LISP" (RL) instead. I am not going to give a definition that will be worth flaming at. The point is that CL makes a _radical_ departure from previous LISP work both in terms of syntax and semantics. 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. >> CL has everything in the >>world in it, usually in 3 different forms and 4 different flavors, with 6 >>different options. >Actually, they decided to omit flavors, because no one could agree on >a standard! :-) >> I think the only thing they left out was FEXPRs... My error here; FEXPRs are easily duplicated. What is really left out is MACROs, i.e. access to the actual form. >FEXPRs are bad (see Pitman's paper in the 1980 Lisp conference) How did all that work get done before 1980? If we'd only known we were doing it wrong :-). Because of the above, I won't bother to address the Pittman paper. >>It is obviously intended to be a "compilable" language, not an interpreted >>language. "Compilable" should read "compiled"... >Can't beat the speed of C programs by running interpreted, you know... But you can get one heck of a better development environment running interpreted... >>it was several years before Golden Hill had lexical scoping, >>and NIL from MIT DOES NOT HAVE A GARBAGE COLLECTOR!!!! >So what do broken implementations have to do with the language standard? 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? >Many of the vaguenesses in the Common Lisp standard are to allow >implementations some freedom to do things in different ways Would >you like it if the *language* standard said that the architecture will >be tagged, and that positive fixnums range between 0 and 32767, and >that they will have a tag of 42? Much of the vagueness will have a direct impact on the user and the portability of code. >Most folks that haven't followed the Common Lisp effort don't realize >how monumental a task it was to get all the Maclispers to agree on a >language standard. There is simply no way to get a Lisp that is both >Maclisp- and Interlisp-compatible. Seems easy enough to me; just put everybody's favorite feature into the language and you can get agreement :-). I do like the casual way Interlisp is just ignored; nothing of any importance has ever been done in Interlisp anyway :-). Being serious, your statement is ridiculous. CL isn't Maclisp compatible either. There is a great range of commonality between Interlisp and Mac-lispish implementations. (We stole from the best for UCI LISP ). But there is also a tremendous rivalry between the 2 camps, and a tremendous financial investment in Interlisp... >>I forgot to leave out the fact that I do NOT like lexical scoping in LISP; >I LIKE lexical scoping in Lisp - dynamic scoping is for special situations, >like rebinding a global variable for the duration of a function (for >instance, one gets an equivalent effect to Unix redirection by rebinding >*standard-input* or *standard-output* to file streams). There is no >good way to do this if you don't have dynamic scoping. Programs that >rely heavily on dynamic scoping are usually sloppily written and extremely >difficult to analyze - things go on behind your back all the time. Thanks for your tutorial, I had NO idea what it was for:-). >Default dynamic scoping in Lisp is the result of history - in 1958, >programming language semantics was not well understood! In another >20 years, no one will understand why anyone would suggest that default >dynamic scoping was a good thing. We are actually fairly close on this issue! I certainly would not design a _new_ language with dynamic scoping as the default. (One of the reasons I state that CL is a NEW language, different from RL). The main reasons I suggest dynamic is preferable in LISP are a) historical, b) LISP is not block structured; the separation of declaring a variable SPECIAL (DEFVAR being recommmend, p 68) from an actual function definition makes it very difficult to debug a function "locally", c) the excessive need to provide compiler declarations makes for some pretty ugly code. Well written LISP code should be almost completely independent of lexical or dynamic scoping considerations. A free variable is obviously special; the only real problem comes in when a variable is bound. >>to allow both dynamic and lexical makes the performance even worse. >This is totally wrong. Say WHAT? It certainly is TRUE in an intepreter; it takes longer to look up a lexical variable than a dynamic variable, and it takes even longer when you have to determine whether the lookup should be lexical or dynamic. Add a little more time to check if it's a CONSTANT or DEFVAR... >To put things in perspective, the Zetalisp language (that the Symbolics >people sell like hotcakes for big bucks) is at least an order of magnitude >larger and more complex than Common Lisp, which they consider to be a small >subset for the exchange of programs. All reports have been that the >Symbolics is super-fast for development and for execution... does anyone >want to contradict me? To put things even more in perspective, Symbolics do not "sell like hotcakes". I don't have the number handy, but I believe the number of units sold is less than 4000. Big bucks is putting it mildly; figure a minimum of $120,000 for a decent, single user system. Zeta-Lisp is bigger, but not in the same way as CL; the "biggness" is in the environment and number of available functions (ala INTERLISP). And it REQUIRES very expensive, very specialized hardware. And nobody runs in CL mode by choice; it slows things down a LOT (and still isn't complete). If you would like to assert that the only way to get a decent CL implementation is to develop a Symbolics class machine for it, I'll be glad to agree :-). But I'm real tired of hearing that LISP "is slow" and requires special hardware ; if you can't work with gp multi-user hardware, maybe you should be doing something else. BTW, I've heard reports that Le-LISP can give Symbolics a run for the money using gp architectures. >Neither would I - it's not *supposed* to be an instructional book. So what is everybody supposed to have learned from? >There are some problems, which is why >there is another version in the works. Almost all of the problems are >extremely technical, and take a long time just to explain to someone not >familiar with the language, let alone to solve... There are also some open problems with language design involved - like compiling to different machines within the same programming environment, and support of program-analyzing programs in a portable manner. No sh*t, Sherlock! You think the flames I've put up are even half? Do you think maybe the drive to make it a "standard" may be just a wee bit premature? >>There is nowhere near the basic underlying set of primitives (or >>philosophy) to start with, as there is in Real LISP (RL vs CL). >Finally, a semi-valid point. There has been some effort to define various >subsets, but no consensus has emerged. Any time someone defines a subset, >everybody whose favorite feature has been left out will rant and rave and >insist that it be included. By the time you're done, you've got the whole >language again (spoken from personal experience!). The point isn't the lack of a subset, it the lack of a starting set. RLs started with a small basic set of types and functions. Even though they grew to tremendous size, the growth was mostly by adding new functions. CL starts out with a tremendous base language, attempting to have everything in it. The user pays the price for this... This also goes along with my earlier explanation about how agreement was reached among the LISP community. You have my sympathies. It was a lot easier in my in the "good ol" days... >As for the non-use of Lisp definitions, most such definitions are either >simple and wrong, or complicated and right. That is almost slanderous; do you really want to stand there and say that about all the other LISP manuals around? I find it a lot easier to understand a well defined function than prose. I always find that I get scr**ed by the sentence I didn't read. Good readers tend to skim. >Chapters 3 and 5 contain information about scoping and binding rules. >Guy Steele has mercifully not repeated the obvious throughout the book! >To answer your question, (SETF x y) *always* expands into (SETQ x y); >see the top of page 94. SETQ sets the lexical binding if there is one, >otherwise the dynamic binding; see the definition of SETQ on page 91 >(where there is a reference to the "usual rules"), and the definition >of "usual rules" in the section on variables, p. 55. I think it would >be impossible to write a language standard that caters to those who >can't read. Thanks for the references. Too bad there aren't any in the book.... 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. Take a look at IEEE and ANSI standards to see what a "real" standard should look like. If I look up SETF, I should be able to find out what it does, not have to read back to the chapter preface. As you so clearly point out, it's a lousy reference manual to boot! >>Then try explaining why SET only affects dynamic bindings (a most glaring >>error, in my opinion). >So how in the world are you going to get this to work in a compiler that >compiles lexical references into positions on stack frames? That's the implementor's problem . It can be done (but probably isn't worth it). See below for how this should have been handled. >> How many books say >>(SETQ X Y) is a convenient form of (SET (QUOTE X) Y)? Probably all >>but two... I will agree that the _definition_ of SET given is definitely useful; what I object to is the capricious changing of the semantics of a function that is so old and so ingrained in RL. It SHOULD HAVE BEEN GIVEN A NEW NAME!!!!!!! (And this applies to every other function whose historical RL definition has been incompatibly changed). CL is supposed to promote compabitility etc.; the first thing it does is become incompatible with most other LISPs. >I use my Lisp 1.5 manual for historical research only (sorry JMC). Maybe you should do a little more historical research! Or at least read something besides Steele and Winston&Horn v2. >> Again, how many years of training, understanding and textbooks are rendered obsolete? >Those folks that managed to pass CS 101 shouldn't have any problem. Passed CS 101 at what school? What year? Using what implementation of LISP? 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. Especially if you have trained other people and your company's business depends on getting debugged software out the door. (Or, in my case, you often make a living debugging other people's code). >MEMQ is a stupid name. So is SHEBS, (the best I can do for an ad hominem argument :-) . But it's obviously distinct from MEMBER, and has a great deal of "historical" weight behind it... >>MEMBER isn't the only case... >This was a tough problem for the designers. On the one hand, everybody >complains about non-obvious names like CAR and CDR and MEMQ. On the >other hand, the considerably better name MEMBER, which ought to be used >to denote *all* sorts of membership tests, had been grabbed up for EQUAL >tests. I would rather have one obvious function name than MEMBER, MEMQ, >MEMQL, MEMBER-EQUALP, ad nauseam. And I *especially* don't want to >write my own membership tests just because I needed to use some specialized >test function!! 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! >I think those who flame about language designs should be forced to >design, implement, and distribute their own language, then listen >while know-nothing second-guessers complain about things they >don't understand to begin with... Terribly sorry I wasn't available to help with the CL definition. On the other hand, perhaps a little more time should have been taken, and some people who weren't completely devoted to a life of developing LISP per se should also have been consulted. Let's face it; design by committee is a polite term. The kitchen sink approach is probably more apt. As you and I point out, one of the key means of getting agreement was including everybody's favorite feature! This ain't "design"... There are a lot of good things in CL, but it's a mammoth compromise and you and I both know it. There are tons of problems and the mad rush to make it a standard is very premature. It's the rush to make it a standard that I object to. It is simply not a good standard. As you say: >Perhaps you should try a non-broken Common Lisp then... >Not in clever implementations... Where are these clever, non-broken Common LISPs? As I also point out, implementation is very costly and the results are forcing many firms to recreate LISP in C to get decent performance for their ES shells. The only "non-broken" versions I am aware of are re-written SPICE! It's hard to believe that MIT can't come up with a version (or if they have, they haven't notified me of the update; last version I have is 0.286). Perhaps you can keep the personal attacks to a minimum next time. You may not know who I am; that doesn't make me an illiterate idiot! I've probably been around a LOT longer than you have, and probably have a much wider range of experience, which is not confined to LISP language development (although we have more LISP designs than you'll ever see). -JJ, CONSART Systems Inc. CIS: 75076,2603 BIX: jeffjacobs