Re: [Caml-list] Re: generic programming

[Chris Hecker <checker@d6.com>]

>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.

Right, I just think they're the same issue, just at different levels of 
detail (and impact on code).  I definitely think "map" et al. are useful, 
and I didn't mean to imply otherwise.  I mean, I am trying to learn a 
functional language after all, so clearly I dig it.  :)

My main point was not about iterators specifically, it was about the flow 
control issue that got brought up when someone said "you don't need 
iterators because you have callbacks".  I was saying that the existence of 
a callback interface isn't always a good substitute for an imperative one.

 > 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?

I need to look at Francois' solution, so I'm not sure yet.  I'm actually 
not running into a problem right now with this anyway, so it's academic for 
me at this point, it was just something I've been wondering about since I 
started learning caml and was mentally comparing it to C++'s templates.  I 
haven't thought about the issues thoroughly, but maybe John Max Skaller can 
comment on whether Francois' iterators are "good enough" for what he was 
trying to write.

>My comment is more along the need of "I don't see when you'd ever need
>to do that, but please enlighten me".

The hashtable example wasn't mine, so I don't know about that.  There's 
also a canonical two-different-shaped-trees example, I think, but I don't 
know much about that either.  I run into this all over the place writing 
games, however.  The GUI thing was one example of a related thing that's 
higher level, but to constrain it to datastructure iteration, often times 
you'll want to do part of an iteration, and then save the state, and the do 
the next part.  So, you'll iterate over some of your AIs this frame, and 
some next frame, to manage your CPU utilization and amortize over multiple 
frames.  I don't know how you'd do that with a "functional iter" (isn't 
that a contradiction? :), although I'm sure someone will come up with 
something insane using continuations and whatnot to prove me wrong.

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