tag:blogger.com,1999:blog-1777990983847811806.post86749182020021634..comments2024-03-16T16:29:29.582-07:00Comments on Haskell for all: pipes 2.0 - Pipe FinalizationGabriella Gonzalezhttp://www.blogger.com/profile/01917800488530923694noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1777990983847811806.post-74787452536997683232012-06-03T11:06:12.668-07:002012-06-03T11:06:12.668-07:00Thanks. Yeah, I was already aware of the monad tra...Thanks. Yeah, I was already aware of the monad transformer law violation, which is why I switched to `FreeT`. I actually reported this same bug for the `free` library here:<br /><br />https://github.com/ekmett/free/issues/3<br /><br />... and I basically stole `FreeT` from Mario Blazevic's `Coroutine` type since I thought he nailed it, except for the name. :)<br /><br />There are a couple of reasons I haven't type-classed `await` and `yield`. The first is because there are some situations where you want to mix both `await`/`awaitF` (like the fold example) and `yield`/`yieldF`. When I generalize the solution to general monoids and comonoids, this will be even more apparent. However, the names could probably be improved.<br /><br />Also, whenever I write type-classes I like to include laws along with them (so that people who make their own instances can verify they wrote a correct instance, although declaring instances "correct by observational equality" seems to be all the rage these days). So I don't actually mind doing this, but I would have to first spend some time thinking about what laws it must satisfy.<br /><br />In this case, I'm warming up to optimizations more and more since they work amazingly well (especially rewrite rules), so I will definitely try out the preprocessor suggestion.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-83474385189867454972012-06-02T20:43:13.568-07:002012-06-02T20:43:13.568-07:00A couple things
1. This is awesome
2. Using the fr...A couple things<br />1. This is awesome<br />2. Using the free monad transformer is an improvement. It is worth mentioning that Pipes 1.0 was not a monad transformer since the free monad over the M (m a) data constructor does not form a valid transformer since <br /> lift $ return x = Impure (M (liftM Pure $ return x)) =/= Pure x = return x<br />3. Why not make await/yield part of a type class and get rid of awaitF/yieldF?<br />4. A safe way to have optimizations and maintain portability is to use the CPPPhilip J-Fhttps://www.blogger.com/profile/03701325990487750739noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-48255812604176920952012-05-21T17:37:51.953-07:002012-05-21T17:37:51.953-07:00Yeah, I'm working on a "pipes cookbook&qu...Yeah, I'm working on a "pipes cookbook" post.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-82687807510036659642012-05-21T17:08:16.127-07:002012-05-21T17:08:16.127-07:00Could write a tutorial or two on how to use pipes ...Could write a tutorial or two on how to use pipes in a practical use-case? I don't exactly understand where I would use this.Jonathan @ jadbox.comhttps://www.blogger.com/profile/12431411201884986208noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-62972997089879928432012-05-21T13:40:14.561-07:002012-05-21T13:40:14.561-07:00That's one good option. There is only one oth...That's one good option. There is only one other problem I could imagine, namely that optimizations will also compromise portability since it will involve using a lot of GHC-specific extensions, but I think that might be okay since if I switch to parametrized monads I will have to do that anyway.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-28792067871172307042012-05-21T11:58:06.740-07:002012-05-21T11:58:06.740-07:00Congrats! Re. "Speed" section: I think y...Congrats! Re. "Speed" section: I think you should consider leaving more elegant or un-optimized versions of functions/types as comments alongside the optimized versions, as I often see in the base libraries. <br /><br />And would it be possible to include some benchmark code in the git repo that you think would be good for people to optimize against?jberrymanhttps://www.blogger.com/profile/11505410150377453045noreply@blogger.com