Re: [Haskell-cafe] (Re arrows and Haskell) ...
On Saturday 06 November 2004 08:36 am, you wrote: < snip >
It might be an immense project, but I also think it would be interesting. I wonder if Haskell would be much faster after being restructured around arrows. If an arrow-based version of Haskell existed, I'd love to try it.
I think it's entirely possible that it would have significant benefits in speed, elegance, and structural simplicity. -- Shae Matijs Erisson - Programmer
Hi Shae! Thanks for your comments, and i agree totally! It would indeed be very interesting, and I tend to agree too that speed might be helped if this were done. ( and yes - I'd love to try an arrow-based Haskell too! ). While I was mulling this over this morning, I was thinking how (or even "if" ) an EBNF grammar (Haskell's in this case) could be represented in terms or arrows. I stopped pretty quickly as it made my head hurt just thinking about it ... :-)) - Andy
Since I have been experimenting with Arrows quite a bit just recently, I feel compelled to add something to the discussion. I too think that Arrow are a beautifully simple and elegant concept. However, once you write production code, you notice quickly that there is a significant difference between a code snippet that's been chosen specifically to illustrate the beauty of Arrows and something else. In my (albeit limited) experience, Arrows are not the answer "to it all" any more than any other clever software design technique is. The moment you need to do things like "apply" an Arrow, you are squarely in the domain of Monads again. So why not write a Monad to begin with? Plus, powerful abstractions that make the code look simple and elegant _always_ come at a price. An Arrow-based stream processor that performs the same task as my monadic BlockIO library does, for instance, results in a module that has half the size the StateT version does. Which is cool. But it is, as of now, also 10 times slower than the monadic version is. Which is not cool at all. It is quite likely that I don't understand Arrows well enough yet to get certain tasks done efficiently with them. But so far my impression is that they are great for certain tasks and not so great for other tasks. Which doesn't really come as a surprise. "One size fits all" doesn't seem to exist in the real world. Peter
On Sat, Nov 06, 2004 at 11:49:45PM +0100, Peter Simons wrote:
Plus, powerful abstractions that make the code look simple and elegant _always_ come at a price. An Arrow-based stream processor that performs the same task as my monadic BlockIO library does, for instance, results in a module that has half the size the StateT version does. Which is cool. But it is, as of now, also 10 times slower than the monadic version is. Which is not cool at all.
That's indeed a rather high cost. Although I suspect that a lot more effort has gone into optimizing Monads than into optimizing Arrows... Cheers, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
On Saturday 06 November 2004 05:49 pm, Peter Simons wrote:
> Since I have been experimenting with Arrows quite a bit just
> recently, I feel compelled to add something to the
> discussion.
>
> I too think that Arrow are a beautifully simple and elegant
> concept. However, once you write production code, you notice
> quickly that there is a significant difference between a
> code snippet that's been chosen specifically to illustrate
> the beauty of Arrows and something else.
>
> In my (albeit limited) experience, Arrows are not the answer
> "to it all" any more than any other clever software design
> technique is. The moment you need to do things like "apply"
> an Arrow, you are squarely in the domain of Monads again. So
> why not write a Monad to begin with?
>
> Plus, powerful abstractions that make the code look simple
> and elegant _always_ come at a price. An Arrow-based stream
> processor that performs the same task as my monadic BlockIO
> library does, for instance, results in a module that has
> half the size the StateT version does. Which is cool. But it
> is, as of now, also 10 times slower than the monadic version
> is. Which is not cool at all.
>
> It is quite likely that I don't understand Arrows well
> enough yet to get certain tasks done efficiently with them.
> But so far my impression is that they are great for certain
> tasks and not so great for other tasks. Which doesn't really
> come as a surprise. "One size fits all" doesn't seem to
> exist in the real world.
>
> Peter
Hi Peter - thanks for this -
It's really good to hear from someone who has used arrows, and you've done
a great job of describing their pros and cons too. ( Ouch - a module running
ten times slower than a monadic version - that's a real performance
hit ... :-)
Anyway - time for me to get into some "pottering around" to become more
familiar with Haskell and what it can do.... Bye for now!
- Andy
participants (3)
-
Andy Elvey -
Peter Simons -
Remi Turk