Douglas Alan <[EMAIL PROTECTED]> writes: > I will certainly admit that Lisp programmers at the time were (and > likely still are) much more enamored of mapping functions than of > iterators. Mapping functions certainly get the job done as elegantly > as iterators most of the time, although I would agree that they are > not quite so general.
In the Maclisp era functions like mapcar worked on lists, and generated equally long lists in memory. It was sort of before my time but I have the impression that Maclisp was completely dynamically scoped and as such, it couldn't cleanly make anything like generators (since it had no way to make lexical closures). > Scheme, on, the other hand, at least by idiom, has computation > "streams", and streams are equivalent to iterators. No not really, they (in SICP) are at best more like class instances with a method that mutates some state. There's nothing like a yield statement in the idiom. You could do it with call/cc but SICP just uses ordinary closures to implement streams. > The canonical way to do this in Lisp would be something like: > (mapcar (lambda (x) (blah x)) xs) At least you could spare our eyesight by writing that as (mapcar #'blah xs) ;-). The point is that mapcar (as the name implies) advances down a list using cdr, i.e. it only operates on lists, not general iterators or streams or whatever. > > x = xs[key] > > I'm not sure what you are asserting? That Common Lisp doesn't have > hash tables? That's certainly not the case. Or that it doesn't > provide standard generic functions for accessing them The latter. Of course there are getf/setf, but those are necessarily macros. > A language like Python, which is defined by its implementation, > rather than by a standard, can move much more quickly. This debate > though is really one more of what is the best model for language > definition, rather than one on what the ideal language is like. Python is not Perl and it has in principle always been defined by its reference manual, though until fairly recently it's fostered a style of relying on various ugly CPython artifacts like the reference counting GC. Lisp accumulated a lot of cruft over the decades and it kept some baggage that it really could have done without. I don't think Python's designers learned nearly as much from Lisp as they could have, and Python has suffered because of it. Lisp still has an awesome beauty in both the CL and Scheme incarnations. But it's like listening to Elvis music--even if it can still get you dancing, at the end of the day it's still a reflection of a bygone culture. -- http://mail.python.org/mailman/listinfo/python-list