Scalaz has the worst iteratee implementation ever. Well, actually that’s not true. It’s a lot better than most. Still terrible though.
2014-01-31 05:11:16Random musing: if I wrote a replacement iteratee framework for scalaz that didn’t restrict abstraction, would it be accepted?
2014-01-31 05:11:55@runarorama I may get on that then. Not sure if it will happen before or after I rewrite Scalaz’s IO monad, but it should happen.
2014-01-31 05:13:06@runarorama Regarding IO: I want the following function: IO[A] => IO[Future[A]] And I want it to parallelize applicative composition.
2014-01-31 05:13:48@djspiewak http://t.co/1xDPL2JwoQ is being replaced by scalaz.concurrent.Task in the near future.
2014-01-31 05:14:47@runarorama Ooooh. That’s almost certainly going to be very nice.
2014-01-31 05:15:01@runarorama The Scalaz 6 iteratees are among the iteratee frameworks that are worse than the Scalaz 7 ones.
2014-01-31 05:15:18@djspiewak In the new scheme, IO[A] is roughly Free[Future, Throwable \/ A].
2014-01-31 05:17:45@runarorama Unfortunately, that’s absolutely not going to do what I want. Free is the problem, not IO.
2014-01-31 05:18:08@runarorama I need a three-state Free: Suspend, Parallel and Pure.
2014-01-31 05:18:16@djspiewak What is it that you want then, and why is it a problem?
2014-01-31 05:18:54@runarorama I don’t think Future quite does what I want.
2014-01-31 05:21:27@runarorama Maybe it does. It’s hard to see. I want an IO that I can write a concurrent interpreter for.
2014-01-31 05:21:42@runarorama I can’t do that *usefully* with IO as it stands, because it doesn’t preserve applicative composition.
2014-01-31 05:21:58@djspiewak Future in the Scalaz sense is a three-constructor thing: Later, Now, Parallel. Free adds recursion, substitution, normalization.
2014-01-31 05:22:09@runarorama Later, Now and Parallel sound much more complex than what I want.
2014-01-31 05:22:38@runarorama I basically want to compose actions just like I do with IO, except that when I apply2, I want that to be distinct from >>=.
2014-01-31 05:23:11@djspiewak Two units, one lazy one strict, and a binary combinator for nondeterministic choice. It cannot be simpler.
2014-01-31 05:23:36@runarorama Except why would I want nondeterministic choice? Why would I want strictness?
2014-01-31 05:23:57