Ask HN: (CL related) Are iterators actually a bad pattern after all?

Some time ago MJD had a blog spat with Ralph Johnson about the nature of patterns [1]. In his example he claimed that the iterator pattern was a sign of a weakness that some languages didn't have. Then he went on to show an example of languages that actually did have this problem [2].

Now it is true that implementing a traversal method on the collection class itself is more powerful in most situations (e.g. Smalltalk: #do) but where I see a problem is e.g. Common Lisp's "mapcar" function. It can map over an arbitrary number of collections.

So my question is; is the iterator pattern bad for implementing this scenario? I looked at the SBCL source code and they seem to be doing exactly this (granted they use closures for iterating, but it doesn't look like the generator strategy to me). I see in [3] they make the case for using generators instead of the iterator pattern but this doesn't look very easy to use on an arbitrary number of collections (in fact I'd like to see an implementation of it, as it's not immediately clear to me how it would be done). Further, I don't see what is being bought here. The function passed to map isn't protected from the collection being mutated by another thread anymore than an iterator would be.

I would certainly agree that Iterator is an inferior approach in most scenarios but for mapcar-like scenarios? What do you think?

[1] http://blog.plover.com/prog/design-patterns.html

[2] He mentioned Perl as not needing this pattern and showed a foreach example. But the fact of the matter is that foreach in Perl can only iterate the built in list type. It wouldn't work on custom made collections.

[3] http://home.pipeline.com/~hbaker1/Iterator.html