Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!hropus!riccb!ihopa!ihnp4!ltuxa!cuae2!gatech!lll-lcc!well!jjacobs From: jjacobs@well.UUCP (Jeffrey Jacobs) Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <1336@well.UUCP> Date: Wed, 25-Jun-86 10:54:04 EDT Article-I.D.: well.1336 Posted: Wed Jun 25 10:54:04 1986 Date-Received: Sat, 28-Jun-86 02:39:58 EDT References: <1311@well.UUCP> <3827@utah-cs.UUCP> <5194@topaz.RUTGERS.EDU> Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Organization: CONSART Systems Inc., Manhattan Beach, CA Lines: 211 >References:<5194@topaz.RUTGERS.EDU <1311@well.UUCP> <3827@utah-cs.UUCP> In <5194@topaz.RUTGERS.EDU>, Charles Hedrick says: >In general, I agree with Shebs' response. A couple more things: Mr. Hedrick does not state what points he agrees with. However, he then goes on to say: >There is nothing in CL that makes a fast interpreter impossible. >There is plenty that makes it difficult. The DEC-20 implementation >has an interpreter that is reasonably fast. The major speed problem >is caused by lexical bindings... I fail to see where Hedrick disagrees with me, unless it's my use of the word "impossible". Since the original article was deliberately "flameboyant" I'll be glad to downgrade "impossible" to "plenty difficult" . >Personally I would have wished for CL to be smaller. As the manager >of a number of timesharing systems, I cringe at a Lisp where each user >takes 8 MB of swap space. This also sounds suspiciously like agreement with my position about CL being a bit overgrown. Just how many UCI LISP versus CL users can a 2060 support? >Simple implementations are slow because >they have to put all of the bindings on lists, thus replacing push by >CONS and pop by a GC. (Note: Hedrick's original msg. had "low", not "slow"). The overhead penalty is not in the CONSing; the time for CONS should be roughly equal to pushing the data on the stack. The REAL overhead is in accessing the data, whether searching a list or searching a stack. If the value of FOO is accessed many times, the overhead increases dramatically. In fairness, should be pointed out that there is possibly BETTER performance in a lexically scoped interpreter using a stack than in a deep bound dynamic environment, as the interpreter would go the value cell if it wasn't found in the lexical environment, as opposed to searching the entire stack. In the case of using a list for the environment, a careful implementation should be able to RETURN the "lexical" environment to the free list on exit, reducing the need for GC. (I assume that he didn't do a GC after every function exit). >What we get for all of >this pain is an interpreter whose binding semantics are compatible >with those of the compiler. I spent several years supporing UCI Lisp. >Many users never compiled code because when they compiled it, it >stopped working. The primary problem was that the binding semantics >changed, and they suddenly had to declare lots of things "special". The code didn't "stop working"; the programmer just didn't know how to do a complete job. It's a matter of not being taught decent programming habits. Versions of DWIM/Programmer's Assistant have been available for UCI LISP since 1972, which make it very easy to keep track of necessary SPECIALs, etc. The notion that gets into student's heads that they can just blindly write code without any forethought or planning is what gives Comp. Sci. grads such a bad reputation in industry. There's really no excuse for failing to understand such a basic principle of the language being used. Some people need to be protected from themselves; LISP (and assembler) are not for them. Let them use PASCAL and M-2. Historically, the default to local/lexical compilation was an obvious optimization, based in large part on the fact that most good LISP programmers wrote very functional code with very little need of dynamic scoping. >In my opinion it is worth a man-month from each implementor to get rid >of this problem. A man-month? See below... > Actually, I voted against this feature of CL. I > would have preferred that the compiler use "special" all the time. >(We did this to a compiler for a variant of UCI Lisp. It helped >things immensely.) You're gonna hate me for this; UCI LISP was meant to be that way when released. Daryle had planned to do it, but didn't have time and forgot to tell me before he graduated. I was so busy with the interpreter and other things that as long as nobody reported bugs, I didn't give the compiler much thought. So it just fell through the cracks . (I'm not sure we could have convinced Rusty, anyway). Development at UCI basically stopped when I left . If you voted against it, it sounds like we agree! >It was turned down, I think for two reasons (1) >This makes the compiler pay in efficiency. Adding lexicals to the >interpreter makes the interpreter pay in efficiency. Since you >compile when you want speed, it makes sense to pick the definition >that is fastest for the compiler This is highly machine and implementation dependent. There are 2 things that must be considered, time to perform the binding and time to access. Time to access is really the key to performance. (Given the overhead involved in CL's extended binding capabilities, time to bind might even be cheaper ). >(2) There are a number of people who >believe that lexical binding is safer, and who want to use lexical >closures. From an overall, general language design perspective, I believe that lexical scoping is better. But there should be a SYNTAX to go along with it. LISP syntax simply doesn't provide a decent distinction between lexical and dynamic; I can go along with either one or t'other, but not mixed. Besides, we need at least one language with dynamic scoping ... >A number of things said in the original posting are just wrong. I can >think of no way to implement SET so it works for lexically-bound >variables in compiled code. There are such things in UCI Lisp. They >are called SPECIAL. I am reasonably sure that SET does not work with >them. If the manual fails to say this, it is a documentation error. If you put on your "stupid ways to do it" cap, you could figure out a way to do it. But it's not really something you would WANT to do. SET has ALWAYS been a problem, more so when interpreted than compiled, due to the shadowing problem. For consistency, CL should have thrown out SET, and defined a new function, maybe SET-SYMBOL-VALUE. But is should NOT have changed the semantics of SET (or MEMBER). The definition of SET in CL is very useful; it's the name I object to. BTW, SET should work with variables declared SPECIAL. I'm not sure what your comment means. >The primary reason for SETF is for convenience in writing code that >writes other code. Examples are macros and code to implement flavors >or other structured-programming constructs... >... However researchers are now beginning to depend upon high-level >tools. We want a macro or other code-constructor to be able to take >the definition of a component and be able to build code to change the >element by sticking SETF around it. It is precisly such large systems >as KEE that make many of the complexities of CL necessary. Perhaps this is why KEE is being rewritten in C :-)? (So are most of the other high end shells. Want to bet that the C implementation looks a lot like "Real LISP (RL")? The results of using constructs like SETF (and similar features in ADA) aren't in yet, and won't be for many years. My personal opinion is that they will prove undesireable due to difficulty in debugging them and "type" problems. I think it's better to write a more specific function that's changeable rather than a "generic" function. But SETF as a macro does involve at least one more EVAL (despite what Shebs said). >But I have no question that the things that >made it bigger will save a number of people time, and facilitate the >building of large systems. My sense of things is that CL >implementations, particularly after they have been in use of a few >years and get tuned, will be about as fast as other Lisps. However >they will be enormous. The attitude of the CL designers was "memory >is cheap". If you envision CL as being used for large systems on >single-user systems, this is right. That's certainly what the CL >designers had in mind. Those of us trying to run large student >timesharing systems may have some problems with this. It may be that >for us a subset will prove helpful. Or the vendors that supply >timesharing systems may simply be more careful in their >implementations, so that all of the code can be shared. They also assume the CPU is cheap!!! There's an old saying: "LISP programmers know the VALUE of everything and the COST of nothing". Have you seen the price for memory launched into orbit lately? It's definitely not cheap! how often have we heard about "artificially intelligent" robots exploring Mars (or wherever). Given the power and weight required for CL, you can forget that one!!! In fact, given the current trend, almost no delivered E.S. system will be in LISP. "Rewriting" it in C after "prototyping" seems well on the way to becoming an acceptable part of the process; you can bet that this will not be economically viable in the real world. It might be cheap when you have a University grant or DARPA to support you; it gets a little more complicated when you have to justify a single user station for $125,000 (or even $50,000) to a manager. Then tell him that once you have it working, you'll have to rewrite it! From a business point of view, I can get a lot VAX for my money... I envision LISP being used for a great many things besides "large systems". It's hard to visualize using CL for a small embedded system. As long as I have been in the field, I have heard that LISP was big, slow and hard to learn. I always said that this was a myth, that reasonably sized, efficient LISPs were available. With CL as a standard, I will be flat out wrong. I think CL has it's place; I also think that the choking off of other LISP development is a tremendous mistake. Yet this is exactly what is happening; implementors feel that "have" to achieve full CL status (whatever that really is; even SPICE isn't fully "Steele"). Disclaimer: My articles on Common LISP are about Common LISP as defined in Guy Steele's book. It is specifically NOT about any particular implementation; although I may point out deficiencies and deviations from CL as defined in Steele, I am not attacking any implementation or person (INCLUDING Guy Steele). There is a great deal of work in CL; it's the mad rush to make it a "standard" that I am against. -Jeffrey M. Jacobs, CONSART Systems Inc., Manhattan Beach, CA CIS:[75076,2603] BIX:jeffjacobs