what if you’re abstracting over functors?
-
-
your functor instance has the execution context.
4 replies 0 retweets 1 like -
your typeclass instance has mutable state?
1 reply 0 retweets 0 likes -
Futures are mutable my dude. (e.g. poll). ExecutionContext seems less mutable to me (what mutates there?)
2 replies 0 retweets 0 likes -
an ExecutionContext is basically a thread pool, very mutable
1 reply 0 retweets 0 likes -
The problem is the presence or the EC violates the monad laws.
1 reply 0 retweets 2 likes -
Which one? Erik has a nice post on this: https://gist.github.com/non/4d1f49fe41e2f12c463ae075bf5d0f06 … — every claim I’ve seen of this involves non-functions. There are totally reasonable non-effectful uses of future for e.g. parallelism that don’t involve non-functions.
2 replies 0 retweets 5 likes -
Functor associativity law. Putting something on a thead pool is potentially“observable” in Scala, so it can break the law.
1 reply 0 retweets 0 likes -
Lots of things are observable in scala (e.g. use toString, hashCode, eq). This doesn’t seem like a strong argument to me. This would rule out all kinds of things.
1 reply 0 retweets 0 likes -
Those are different in that they abuse “object”. Even if we had true parametricity in Scala, the EC still breaks the associativity laws, no?
2 replies 0 retweets 0 likes
Correct, it does. You don't even need to talk about side-effects to demonstrate that there is no Functor here. It can be improved such that there is, though.
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.