-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StateT violates laws #1714
StateT violates laws #1714
Conversation
As pointed out [here](typelevel#1640 (comment)) This reveals law violations in `StateT`. It looks like `flatMap`/`ap` consistency does not hold, as well as `MonadCombine` right-distributivity. It's not immediately clear to me how to fix this, so I'm opening this up in case somebody else gets to it first.
ouch |
@ceedubs Just to short-circuit some work, I assume you found the inconsistency issues in |
@ceedubs Oh, I can't read. I thought this was an issue, not a PR. :-P |
to save a trip to the CI to get the actual error message:
I probably missed something but I didn't find error for |
found it, apparently
|
I'm pretty sure I know what's going on here. tl;dr: I don't think it's sound to define |
@djspiewak Sorry I haven't had a chance to come back to this, but what you are saying is what I was fearing might be the case. I'm not sure how to proceed. I remember that some time back @TomasMikula had a POC of a stack-safe |
Here's a slightly more rigorous treatment of my intuition from earlier…
|
@ceedubs I'll look into the reformulation. Shouldn't be too hard, I think, and I doubt it will break down with |
I wonder if another way to fix this might be to hide the representation from the user, and just make the constructors consistent. Edit: How does it make sense that StateT not being a monad would break the ap/flatMap consistency law, and not the flatMap associativity law? It sounds to me like we have an incorrect implementation of ap. |
An update on this: I spent some time talking with @jdegoes about the issue last week, and some playing around with strawmen convinced me that I overgeneralized the problem a bit. We definitely can't override Critically, all of the "nested monad" breaking examples (notably, from @TomasMikula and the classic Haskell At any rate… Still pushing on this. We'll see where it leads. |
As pointed out here
This reveals law violations in
StateT
. It looks likeflatMap
/ap
consistency does not hold, as well as
MonadCombine
right-distributivity. It's not immediately clear to me how to fix this,
so I'm opening this up in case somebody else gets to it first.