Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!ut-sally!utah-cs!shebs From: shebs@utah-cs.UUCP (Stanley Shebs) Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <3837@utah-cs.UUCP> Date: Sun, 29-Jun-86 18:30:17 EDT Article-I.D.: utah-cs.3837 Posted: Sun Jun 29 18:30:17 1986 Date-Received: Mon, 30-Jun-86 05:57:36 EDT References: <1311@well.UUCP> <3827@utah-cs.UUCP> <1316@well.UUCP> Reply-To: shebs@utah-cs.UUCP (Stanley Shebs) Distribution: net Organization: University of Utah CS Dept Lines: 380 In article <1316@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > >In <3827@utah-cs.UUCP>, Stanley Shebs responds to >my original article, <1311@well.UUCP> jjacobs@well.UUCP... > >>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. I suppose at this point it's appropriate for me to put on my know-nothing hat and proceed to comment on the design (or lack thereof) of UCI Lisp. There's a manual right here... >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. Well in that case, let me substitute the term "Obsolete Lisp". People take a dimmer view of poorly defined semantics nowadays - it's no longer OK for Lisp to be "Fortran with parentheses". >>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... Sure - I use the interpreter too. But WHO CARES about the *performance* of the interpreter!!! >>Many of the vaguenesses in the Common Lisp standard are to allow >>implementations some freedom to do things in different ways > >Much of the vagueness will have a direct impact on the user and the >portability of code. Yeah, like improve portability, at least when programmers adhere to the definition of the language. Are you suggesting the language standard for the interchange of programs should read like the UCI manual and say that 577777Q represents zero? I don't think that non-DEC-20 people would like that part of the specification very much! >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 ). Somehow I doubt a UCI Lisp program using the ";" or ";;" functions is going to work very well in Maclisp. Square brackets in UCI Lisp and Franz won't go over real well in PSL, where they denote vectors. UCI Lisp and PSL are the only dialects to define functions with a macro DE, while Maclisp and Franz use defun, and Interlispers do it in several different ways. CL is just as compatible with older dialects as the older dialects are with each other! But once you convert to the standard, you don't have to do it any more... It's very misleading to suggest that there isn't a lot of pain and agony to translate one dialect of "Real Lisp" to another. Tim Finin wrote his Franzlator to convert Interlisp code to Franz, and it had hundreds of conversion rules. Common Lisp has the advantage that a number of experienced Lisp implementors met and argued about most aspects of the language, while some of the features of older dialects look like they were put together by an undergrad that had been dropped on the head as a child. PSL has this function DELATQIP for instance, which does destructive deletions on alists using a key, while UCI Lisp has a function SPEAK which returns the number of CONSes executed (although it is not said whether this count is reset between GCs - a rather glaring screwup). Franz defines (and documents!) operations for beating on allocated number cells directly, so one can globally change 3.1416 to be 2.72 (sort of like the undocumented feature of certain Fortrans). >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. Huh? Declaration for what? Local variables? >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. (let ((num 45)) (mapcar #'(lambda (x) (+ x num)) '(3 4 5))) I would prefer num to be lexical and not dynamic, even though it is free within the inner lambda. It's also not desirable for typos to suddenly materialize as specials - it would be a tough debug to find. >>>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... Ah, we're talking about the interpreter again. I still don't understand why anyone would think interpreter performance would matter - the overhead is so tremendous already that dynamic/lexical lookups aren't necessarily significant. >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. I don't use Lisp machines, I expect my (compiled) Common Lisp programs to go faster than equivalent C programs, and I beat on the compiler if they don't go fast enough. >>Neither would I - it's not *supposed* to be an instructional book. > >So what is everybody supposed to have learned from? Rodney Brooks has a book "Programming in Common Lisp", Bob Kessler is working on a book that features objects and Common Lisp, and of course the 2nd edition of Winston & Van Horn's "LISP" uses Common Lisp. >>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? These problems certainly aren't solved in UCI Lisp either! >Do you think maybe the drive to make it a "standard" may be just a wee bit >premature? So when is it going to be less premature? When we have 40 mutually incompatible Lisp dialects instead of only 10? >>>There is nowhere near the basic underlying set of primitives (or >>>philosophy) to start with, as there is in Real LISP (RL vs CL). It's definitely an exaggeration to suggest that UCI Lisp has some basic underlying set of primitives that CL doesn't. >>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. Interlisp grew by adding magic flags to every property list in sight. >CL starts out with a tremendous base language, attempting to have everything >in it. The user pays the price for this... Tremendousness is in the eye of the beholder. A lot of people want to make Common Lisp even bigger. The other aspect (which I mentioned originally) is that one wants to standardize on user functions, rather end up in a situation where each site has massive and mutually incompatible libraries, which defeats portability. For instance, the UCI Lisp sort function lexorder is quite different from PSL's gsort. UCI Lisp's set intersection function takes any number of arguments, while PSL's only allows 2. The user pays the price, in porting effort. >>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. I was exaggerating perhaps, but it does happen. Definitions in manuals are "wrong" if they differ from the source code, which might have error checks or other argument processing. For instance, the UCI Lisp manual has a definition of EQUAL that doesn't say anything about what happens when comparing arrays, although I might guess that it returns nil. Without a copy of source code, I can't really be sure. Sure, you can explain member and some other list functions by definition, but that's about it. For instance, (push x place) sort of expands into (setf place (cons x place)), except that place will get evaluated twice, so the real macro has to be trickier. UCI Lisp avoids this by only allowing variables as places to push things, which is a nuisance. I also notice that the UCI manual doesn't have definitions for any of the array functions, or string functions, or explode, or many others. >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. SETF contains a fine description of what it does. It is clearly unreasonable to expect that the description of SETF should also include documentation on SET, RPLACA, and everything else that it expands into, or tutorial material on the handling of symbols and their values. A "real" standard (there's that word "real" again!), for instance my copy of the Ada standard, has *hundreds* of cross references. You can bet that when Common Lisp becomes an ANSI standard, its document will be just the same. >>>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. Presumably UCI Lisp does it wrong too, since the manual notes (p. 105) that "In compiled functions, SET can be used only on globally bound and SPECIAL variables". Should I assume that this gross difference in the behavior of compiled and interpreted code is another "optimization"? >>Those folks that managed to pass CS 101 shouldn't have any problem > [with different languages] > >Passed CS 101 at what school? What year? Using what implementation of LISP? We try to teach our students enduring principles while encouraging them to be flexible in the minutiae of languages and programs. >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. That's life in Lisp land. Personally, I welcomed most of the changes in Common Lisp, since they were considerable improvements over the bizarrities of other dialects, which I had been annoyed at for a long time. >>MEMQ is a stupid name. > >So is SHEBS, (the best I can do for an ad hominem argument :-) . Maybe you should put a SHEBS function in UCI Lisp then - it takes any amount of arguments and returns a random flame! >But it's obviously distinct from MEMBER, and has a great deal of "historical" >weight behind it... "Historical weight" - spare me! This isn't Fortran or Cobol, whose definitions haven't changed significantly in almost the entire history of computer science! >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. Ah, but if we call it DIFFERENT-MEMBER-WITH-JJ-APPROVED-NAME, then many people will complain because the name is too long, or because it's different from MEMBER, or any number of other reasons. >But don't kill my working code that goes back many years!!!! Nobody's forcing you to use Common Lisp. You're perfectly free to fall into the backwaters of computing. >And don't >invalidate all of the text books, articles, etc that have already been >written and used for many years! Too late, the 1959 LISP Programmers Manual is already invalidated. >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"... Methinks you're getting rather inconsistent. On the one hand, you accuse CL of being specified by including everybody's favorite feature (presumably from pre-existing Lisps); on the other hand, you say that it's a new language that is incompatible with Lisp. Both of these assertions can be true only if the pre-existing Lisps were fundamentally incompatible. But you've already claimed that they are all "Real Lisp" and basically the same! >There are a lot of good things in CL, but it's a mammoth compromise and you >and I both know it. Suppose the Common Lisp committee had all been dropping acid and decided UCI Lisp was "the Ultimate". Non-UCI-Lispers would have promptly ignored the committee and continued to go their own ways. It is interesting to note that the Lisp community has been converging faster on Common Lisp than the DoD types have been standardizing on Ada, and there has been no official dictum that Common Lisp will be used for projects. There is a lot to be said for compromise when the circumstances demand it. >There are tons of problems UCI Lisp (and Franz and PSL and Interlisp) have megatons of problems then. >>Perhaps you should try a non-broken Common Lisp then... >>Not in clever implementations... > >Where are these clever, non-broken Common LISPs? PCLS isn't bad, although it's a subset. But then it's had only about one person-year put into it. Try VAXLisp or Lucid Common Lisp (which has a hot compiler) or HP Common Lisp or Symbolics Common Lisp or Kyoto Common Lisp. >the results are forcing many firms to >recreate LISP in C to get decent performance for their ES shells. I don't know which companies you might be referring to, but the ES shells I've had occasion to examine have such brain-damaged algorithms no amount of translating to various languages is going to help them. Recall the usual shibboleths about benchmarking and performance analysis... >The only "non-broken" versions I am aware of are re-written SPICE! PCLS has a couple functions stolen from Spice, but it's mostly new code. Symbolics Common Lisp is all their own. HP is careful to emphasize that their Common Lisp is not based on Spice, but that's not necessarily an advantage. Spice is good code. You could do a lot worse, especially if you don't pay attention to the specification. >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). MIT isn't some sort of magical place whence optimal correct code appears every so often. There aren't many people there willing to build their own Lisp anymore; they either go with a commercial version or hack Scheme instead (a lot of Common Lisp features derive from Scheme, by the way). >You may not know who I am; that doesn't make me an illiterate idiot! I don't *care* who you are; I just go by your statements. >I've probably been around a LOT longer than you have, Probably true - certainly I can't get into an early 70s Lisp frame of mind without working at it. >and probably have a much wider range of experience, There used to be people with a great deal of experience designing oared galleys, but they weren't very helpful with modern programming languages. >we have more LISP designs than you'll ever see So where are all these great Lisp designs eh? Are any of them implemented? Why don't you subject them to public scrutiny? >-JJ, CONSART Systems Inc. Probably everybody is getting tired of this. There is a particular topic that I would be glad to discuss further, which is the rationale for the various design decisions that went into Common Lisp. Many people have asked about various features good or bad, and when I've gone to look into my historical material, there have been some interesting discoveries. For instance, did you know that an early draft (the "Swiss Cheese Edition") proposed no less than 578 functions to operate on sequences? It was some time before it occurred to anyone that keywords might reduce the number of functions. So far, I've been able to find some pretty solid reasons even for some of the most bizarre Common Lisp features. So if anybody has questions, post or mail me, and I'll try to find out the real story and explain it. stan shebs