@djspiewak @nuttycom I can show you one which is not OptionT.
-
-
Replying to @puffnfresh
@puffnfresh@nuttycom If you’re claiming F ~> IO, then you should be able to define it for all F.1 reply 0 retweets 0 likes -
Replying to @djspiewak
@djspiewak@nuttycom nope, it's not F which is universally quantified.3 replies 0 retweets 0 likes -
Replying to @puffnfresh
@puffnfresh@nuttycom But it is! I’m talking about LiftIO here. You’re claiming forall F . LiftIO[F] => (F ~> IO), which is impossible.1 reply 0 retweets 0 likes -
Replying to @djspiewak
@djspiewak@nuttycom wow, I did not claim that. I would never.3 replies 0 retweets 0 likes -
Replying to @puffnfresh
@puffnfresh@nuttycom Because all LiftIO[F] must be able to define F[Unit] => IO[Unit], and all programs need it, it should be on the class.2 replies 0 retweets 0 likes -
-
Replying to @puffnfresh
@puffnfresh@nuttycom Please show me an example program *in Haskell* which uses an IO-based monad trans stack and doesn’t use this function.2 replies 0 retweets 0 likes -
Replying to @djspiewak
@djspiewak@puffnfresh@nuttycom A [anything] program with an IO-based monad trans stack is rubbish. Yes I know they are out there.2 replies 1 retweet 0 likes -
Replying to @dibblego
@dibblego@puffnfresh@nuttycom I agree in principle that it’s a lot nicer when you can push your effects down in the stack.1 reply 0 retweets 0 likes
@djspiewak @puffnfresh @nuttycom It's what all the sensible programmers do.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.