[Haskell-cafe] ANNOUNCE: arrow-list. List arrows for Haskell.

[Sebastiaan Visser]

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/