On Tue, Sep 4, 2012 at 2:19 AM, john skaller
<skal...@users.sourceforge.net>wrote:
>
> 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.
>
>
When it comes to parallelism I've heard Erlang is claiming to be on top of
this one. Might be worth studying their approach a bit to see if it's
relevant to what you're talking about.
------------------------------------------------------------------------------
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
