Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!ut-sally!pyramid!hplabs!well!jjacobs From: jjacobs@well.UUCP (Jeffrey Jacobs) Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <1372@well.UUCP> Date: Tue, 1-Jul-86 21:57:15 EDT Article-I.D.: well.1372 Posted: Tue Jul 1 21:57:15 1986 Date-Received: Thu, 3-Jul-86 05:57:28 EDT References: <1311@well.UUCP> <3827@utah-cs.UUCP> <1316@well.UUCP> <3837@utah-c Organization: Whole Earth Lectronic Link, Sausalito, CA Lines: 266 s.UUCP> Sender: Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Followup-To: Distribution: net Organization: CONSART Systems Inc, Manhattan Beach, CA Keywords: In <3837@utah-cs.UUCP>, Stan Shebs writes: >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... and goes on to beat on UCI LISP. I don't know why he bothered; nobody suggested it should be a standard, or was without problems. With the necessary changes, it might be a good model for a subset of CL (i.e. range and number of functions, etc). But we already know what happens when a subset is attempted :-) >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! No, I'm not suggesting any such thing. The manual(s) are a description of the language implementation, not a "specification". (And it was originally written for a DEC-10). I do think that _parts_ of the manual provide a good example of how things should be written; much of this is actually from the Stanford 1.6 manual. (I also wish that Meehan had done some _real_ editing on the book; there are still typos from the original 1973 Tech Report)! >>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!!! I care about the performance of the interpreter; development time costs $ (in the real world). A bad interpreter seriously impacts productivity. The longer I can work in the interpreter, the more I can produce. Let's also not forget that (APPLY foo args), where foo is an arbitrary structure results in interpretation, not compilation. >Yeah, like improve portability, at least when programmers adhere to >the definition of the language. It will be interesting to see just how "portable" things will really be. C is nowhere near as portable as many people claim; I suspect that due to the size and complexity of CL that we will see the same problem, (particularly with so many implementations being "broken"). >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. Is that UCI, Franz or INTER-LISP's fault? They all came before PSL, so it's really PSL's fault. Maclisp used to use DE (and I'm sure it's still there). Remember, the basic order of creation was MAC->Stanford 1.6->UCI. >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. Translating between Interlisp and MacLisp derived versions was ALWAYS a pain; between MacLisp types it was much less so. (I did CNNVR in about a week). There used to be a program called TRANSOR that worked pretty well; did it get lost? Or does everybody feel the need to start from scratch... >>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? No, declarations of SPECIALs. >>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. The example you give is meaningless. The results are identical for either case.' *PLEASE NOTE* that my gripe with CL is that it allows BOTH dynamic and lexical binding. (DEFUN FOO (X Y Z)... can get you in even WORSE trouble if X, Y or Z has been DEF'ed previously. Dynamic is my *personal* preference; I can live with lexical without much heartburn. Allowing both is crazy. CL should have come up with a different mechanism for dynamic binding (maybe DLAMBDA, DLET and DLET*). >>>>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. It is VERY significant. Variable reference is certainly the most frequent operation in LISP (CL or RL). HISTORICAL note: it is much easier to build a dynamically scoped compiler. The access time to a special cell is equivalent to a stack based variable. A version of UCI LISP at Rutgers did just that; the original release of UCI would have had this, but it fell through the cracks. The main reasons for the lexical scoping in the compiler was space and speed; dynamic binding required an extra PUSH and space on the stack. Memory was a much more critical resource in those days. (I have already pointed out that it was an obvious optimization based on observed coding practices). I assume that nobody would complain if the compilers had also been dynamic, resulting in identical semantics :-) >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. That's great, but not everybody in the world is going to have a compiler beater handy. (And I would certainly like to see your system). >Tremendousness is in the eye of the beholder. A lot of people want to >make Common Lisp even bigger. No argument here. LISP development is a disease akin to drug addiction or alcoholism; once you start, you can't stop! One of my gripes with CL is that there are too many ways to do the same thing. >>>As for the non-use of Lisp definitions, most such definitions are either >>>simple and wrong, or complicated and right. >>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. If you read it carefully, you will find that an ARRAY is a SUBR; EQUAL would compare the values. The aren't "wrong" as long as the result is specified by the given definition. Steele's book could be MUCH better... >Maybe you should put a SHEBS function in UCI Lisp then - it takes any >amount of arguments and returns a random flame! "Random" is the key word :-). >Too late, the 1959 LISP Programmers Manual is already invalidated. So are about 100 or so other books. >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. Aha! So the real point is that ANY standard is good, not that CL is a good standard!!! My point is that CL is not a good standard... (However, I have been know to compromise when the circumstances demand it). >>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. Lot's of subsets around, aren't there ? Last time I checked, neither HP nor Symbolics were "Steele complete"; there were still things either not meeting the standard or still missing. I haven't had a chance to try the other 2. It is still necessary to stay away from some of the more subtle aspects of the specification (in fact one should probably stay away from them anyway). >>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... Inference, Carnegie Group and Teknowlege to start. KES II and NEXPERT are both written in C. I was apparently wrong about Intellicorp converting KEE to C (although from what I hear they should). >>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. Do you mean the Steele specification? If so, and they don't meet it, aren't they "broken", i.e. non-portable and non-CL? >>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? Like I said, Lisp development is a disease, once you get it you can't get rid of it. However, these designs are proprietary, and wouldn't be of much interest to you anyway. Some of the work will be published, but publication isn't a very high priority (remember, I'm in industry, not academia). They are the result of applying years of software engineering experience rather than any great theoretical advance. Mostly practical solutions and a couple of new "laws" on garbage collection. -Jeffrey M. Jacobs, CONSART Systems Inc., Manhattan Beach, CA CIS:[75076,2603] BIX:jeffjacobs