]> > [Lots of interesting points about "push" vs. "pull" APIs omitted] All you said is very reasonable, but I think you're generalizing the discussion (especially with the GUI examples) beyond what I had in mind, i.e. iteration over in-memory data structures. In particular: > Giving up explicit control over the flow of your program is a > serious problem in my opinion When the task at hand is sufficiently abstract, e.g. "visit every element of this set once", or "transform this list by applying this function to each element", explicit control over the flow is something that I'll gladly omit. (Just like I'm happy not to have explicit control over memory deallocation.) In other terms, are you really saying that you prefer writing for (Enumeration e = l.elements(); e.hasMoreElements(); ) frobnicate((SomeClass) e.nextElement()); over writing List.iter frobnicate l > It seems like it's something a good language should support well. > [...] > I wish Ocaml supported imperative/pull coding styles better, which > is why I'm interested in this thread. The language provides full imperative power, and it's easy to write imperative iterators over concrete data structure (like François showed). So, what more would you like? True, abstract types provided by the standard library do not provide imperative iterators (heavens forbid :-); but there are about three of them (Set, Map, and Hashtbl), so I don't think this would really stop you, should you embark in writing STL-style or java.util-style code in OCaml... > 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) My comment is more along the need of "I don't see when you'd ever need to do that, but please enlighten me". Say you have two hashtables; please show me a situation where iterating in parallel over the two hashtables (using two imperative iterators) would be more convenient than what you can write with OCaml's current hashtable interface (only functional iterators). - Xavier Leroy ------------------- 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