Couple of thoughts/observations: - Erlang has a vm, so that would avoid building a vm.
On the downside, erlang is not pure: the message-passing and the io: commands imply the possibility of side-effects. Still, it could be good enough for a proof-of-concept? - implementation as a library function? Instead of building/modifying a vm to re-implement how map works, perhaps an easy way of doing this would be to create a new map function (dpmap? (=Dynamic parallel map), which chats to a scheduler process, which decides whether to split the map or not. Downside: constant overhead for all maps, even really small ones that would otherwise run really fast, and will ultimately be assigned only a single process anyway. (note: using erlang terminology here, where "process" means essentially "thread"). Of course, even modifying the vm to parallelize maps etc would have a constant overhead, but possibly the overhead could be much smaller if implemented directly in a vm? Possibly an approach could be: - impliment as a new dpmap library function - someone could optimize this in a vm later _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
