>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