On 04/09/2012, at 3:15 PM, Dobes Vandermeer wrote: > Well it sounds very interesting, not sure I understand all of it.
Not sure i do either :) > > However, a few thoughts did come to mind ... > • If you're going down the "parallel" route, keep in mind that all > elements of any collection could be processed in indeterminate order and > maybe in parallel ... so if one has an array this could also use parallelism > if available. > • Many trees actually are considered "ordered", like a red-black or AVL > tree, even though they aren't necessarily indexed numerically > • Probably order of operations should be selectable to some degree by > programmer: "serial pre-order, serial breadth-first, parallel, don't care" You can already so this with an iterator, i.e. some visitation algorithm producing a stream. What we seek here is as you mentioned in earlier point: a way to at least allow concurrency as an optimisation: clearly you cannot get parallelism with N threads unless you have N processors. However there's something more than this. The ordering here I think should be driven by the *consumer* not the producer. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
