begin quoting Andrew P. Lentvorski, Jr. as of Wed, Feb 02, 2005 at 10:36:05PM -0800: > > On Feb 2, 2005, at 8:48 PM, Stewart Stremler wrote: [snip] > >Weren't the first lisp implementations built that way? Or do those > >count as "toy implementations" as well? > > Sure, the *first* implementations were probably built that way. > However, most of the various dialects by 1980 had much better > implementations.
Naturally. It's an obvious thing to optimize on. And if the optimization is relatively transparent and doesn't change the syntax of the language, it's conceptually irrelevent ... everything behaves /as if/ it were all cons-cells. [snip] > >Surely that doesn't have to be visible to the programmer? > > Yes and no, but the problem is not confined to Lisp. I can build my > vectors out of cons-cells--then I get O(n) accesses and length, but > inserts and deletes are O(1). I can build my cons-cells out of > vectors--then I get O(1) accesses and O(1) length, but then inserts and > deletes are O(n) as I have to copy things around. That's just standard big-Oh concerns. I got that, and haven't considered it relevent for this discussion. The performance of the lispish languages has never really been an issue one way or another, at least for me. > How visible is O() performance to a programmer? Depends what they are > doing. I'd say that O() performance isn't visible to a programmer except in the programmer's own code; you need to bump up to an analyst, tester, scientist, or an engineer's level to worry about O() performance. Most programmers seem to be lousy at O() anyway, from what I've read in the past. [snip] > The generic sequence accessors normally paper over this problem. So, > the same code tends to work for all types. Okay, that's what I was looking for. I was getting the impression that there were fundamental syntactic differences in using the different data types. I didn't think that CL would do something that...wrong. -Stewart "Taking advantage of tail recursion requires a little thought" Stremler -- KPLUG-List mailing list [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
