Becoming Productive in Haskell

Re:Becoming Productive in Haskell by windlep on Friday April 24, 2015 @06:17PM (#9436305)

I actually thought that too, but I guess that's not the case. I helped write some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it wasn't fast enough as the lib author later rewrote all the attoparsec code to use pointers to the underlying byte buffers.

https://github.com/kazu-yamamoto/http2/commit/0a3b03a22df1ca...

The stream fusion stuff is sweet, but not exactly unique to Haskell since any language with good iterator/generator abstractions have similar constant-time memory characteristics.

[ Parent | on HN ]

Re:Becoming Productive in Haskell by zoybert on Sunday April 26, 2015 @11:40AM (#9442072)

I believe you're misunderstanding what stream fusion is. A language compiler does not really need "good iterator/generator abstractions" more than a guarantee of side-effect free transformations in order to be able to de-forest the intermediate data structures. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...

[ Parent | on HN ]

Re:Becoming Productive in Haskell by windlep on Sunday April 26, 2015 @12:19PM (#9442223)

I meant more that languages with an iterator/generator usually have similar constant space usage. That is a drastic oversimplification of stream fusion and fails to mention other practical outcomes as you mention, along with a variety of optimizations.

I found this posting a little more approachable to seeing the various optimizations possible with stream fusion: https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-...

[ Parent | on HN ]