On 2009-11-13, at 23:39, Robert Brown wrote, quoting me: > Common Lisp blends together features of previous Lisps, which were designed to > be executed efficiently. Operating systems were written in these variants. > Execution speed was important. The Common Lisp standardization committee > included people who were concerned about performance on C-optimized hardware. Guy L Steele, Jr., `Common Lisp The Language' 1/e (1984). p. 1 `COMMON LISP is intended to meet these goals: Commonality [...] Portability [...] Consistency [...] Expressiveness [...] Compatibility [...] Efficiency [...] Power [...] Stability [...]' The elided text amplifies each of the points. I repeat: the purpose of Common Lisp was to have a standard Lisp dialect; efficiency was less of an issue for those investigators.
As for C-optimized hardware, well, the dialects it aims to be compatible with are ZetaLisp (Symbolics Lisp Machine), MacLisp (PDP-10), and Interlisp (PDP-10, originally). CLtL mentions S-1 Lisp as its exemplar of high numerical performance. Unfortunately, S-1 Lisp, written by Richard Gabriel and Rod Brooks was never finished. MacLisp was a highly efficient implementation, as I've mentioned. I worked at BBN at the time Interlisp flourished; it was many things, some of them quite wonderful, but efficiency was NOT its goal. > The Scheme standard has gone through many revisions. I think we're up to > version 6 at this point. The people working on it are concerned about > performance. Yes, they are. You should see <a>'s rants about how <b> specified certain features so they'd be efficient on his implementation. I had real people's names there, but I deleted them in the interests of not fanning flamewar flames. > For instance, see the discussions about whether the order of > evaluating function arguments should be specified. That was a long time ago, and had as much if not more to do with making arguments work the same as let forms as it had to do with efficiency. But I'll point out that the big feature of Scheme is continuations, and it took quite a few years after the first Scheme implementations came out to make continuations stop being horrendously *IN*efficient. > You can't point to Rabbit (1978 ?) as > representative of the Scheme programming community over the last few decades. I didn't. I used it to buttress YOUR argument that Schemers have always been concerned with performance. >> Using Python 3 annotations, one can imagine a Python compiler that does the >> appropriate thing (shown in the comments) with the following code. > I can imagine a lot too, but we're talking about Python as it's specified > *today*. The Python language as it's specified today is hard to execute > quickly. Not impossible, but very hard, which is why we don't see fast Python > systems. Python 3 annotations exist. Check the Python 3 Language Reference. I notice you've weakened your claim. Now we're down to `hard to execute quickly'. That I would agree with you on, in that building an efficient Python system would be a lot of work. However, my claim is that that work is engineering, not research: most of the bits and pieces of how to implement Python reasonably efficiently are known and in the public literature. And that has been my claim since the beginning. -- v -- http://mail.python.org/mailman/listinfo/python-list