@djspiewak @nuttycom nope, it's not F which is universally quantified.
-
-
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 It’s not always practical to do that. Always possible, surely, but I’m not sure about practical.1 reply 0 retweets 0 likes -
Replying to @djspiewak
@djspiewak@puffnfresh@nuttycom Show me an example of a program for which it is not. They are so exceptional that nobody ever proposes them1 reply 0 retweets 0 likes -
Replying to @dibblego
@dibblego@puffnfresh@nuttycom Yes, because all such programs fit easily into a pastebin link.1 reply 0 retweets 0 likes
@djspiewak @puffnfresh @nuttycom I have no idea how that might follow from poorly written (IO-based monad stack) programs.
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.