]> >Like François, I find functional iterators so much cleaner >and better structured. Moreover, the extra "power" of imperative iterators >isn't obvious to me. I think this is a very important point, but I totally disagree with your conclusion. Giving up explicit control over the flow of your program is a serious problem in my opinion, and callback solutions force you to do that. Iterating over two things at once is an obvious example of where it breaks down, but it happens in a lot of places. Real closures make it less painful to deal with this than in languages without closures, because you can have the map/iter code right there acting locally, but closures still don't really eliminate the problem that you aren't in control of when that code gets called anymore. As another example, this idiom/pattern actually shows up a lot in GUI APIs for things like events. I think it's pretty clear at this point that callback based event handling code leads to more lines of less readable and harder to understand code than having the client code be able to pull things off a queue when it's ready for the events. I'm sure some disagree with this statement. Both of these are examples of "push versus pull" interfaces, and pull just seems to work better. Having data pushed at you means you often end up buffering it on your end to manage your flow control anyway unless you're just doing some trivial processing. Furthermore, it seems like it's a common trap to fall into saying the familiar "you don't want to do that" (like your comment about hashtables) when there's a fair amount of evidence that it's reasonable thing to want to do (and I think better in a lot of ways). It seems like it's something a good language should support well. I'm not saying that callback/push interfaces are always bad, just that there are strengths and weaknesses to both. To reference the XML thread, there's a reason there are both DOM and SAX interfaces. I wish Ocaml supported imperative/pull coding styles better, which is why I'm interested in this thread. It's late...hopefully this mail made some sense. Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners