On Nov 7, 2010, at 1:40 AM, Sebastian Fischer wrote:
> On Nov 6, 2010, at 10:00 PM, Sebastiaan Visser wrote:
> 
>> List arrows are a powerful tool when processing XML, building query 
>> languages and lots of other domains that build on functions that might 
>> return more than one value as their output.
> 
> Interesting. Do you plan to write some examples that show
> 
>  * how to use ListArrows,

Yes, I certainly am. Although, time is currently not on my side. I'm planning 
to write up a blog post about using list arrows for XML processing.

>  * differences to using the list monad, and
>  * when using ListArrow is preferrable?

Currently I'm playing with the idea of a translation of XML list arrows in 
Haskell to DOM operations in JavaScript. The lack of ArrowApply (the full power 
of monads) allows you to inspect your computations, this makes translations to 
other languages possible.

> I'm interested to see something like this worked out although I have some 
> rough ideas like "monads are more powerful and arrows may allow stronger 
> reasoning and more efficient implementations". Can you substantiate these 
> general points for the concrete case of ListArrow vs list monad?

Beside the fact that, after playing with them for while, I find arrows more 
convenient to use than monads, the ability to inspect their structure can help 
you to optimize them.

Maybe this sounds weird on the Haskell mailing list, but at Silk[1] we have a 
full implementation of (functional reactive) list arrows in JavaScript. The 
arrows build up an AST of operations that we statically optimize to a more 
efficient form. This is needed because JavaScript itself is not going to fuse 
intermediate list for you.

I'm reinventing all of this in Haskell now to gain more insight in what we've 
actually done in JavaScript. :-)

> I assume your implementation is *not* more efficient than the list monad as 
> it builds on ListT.

That is entirely true.

But this is only implementation, different implementations may be possible that 
are more efficient. As long as ArrowApply is not involved static optimization 
might be possible that fuses intermediate lists, as far as the compiler is not 
already doing so. 

I'm also planning to investigate whether it is possible (useful) to perform the 
list computations (the map in concatMap) in parallel. I'm not sure if someone 
has already tried this for list monads.

> Sebastian

Sebastiaan

[1] https://blog.silkapp.com/2009/12/reinventing-xslt-in-pure-javascript/

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to