-
Notifications
You must be signed in to change notification settings - Fork 91
Interplay between Apply
and Bind
#158
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I think maybe the situation as it is is correct? As long as there is no If we did move the |
The problem isn't between The identity laws for |
Took me a while to get around to reading this but yes, I'm totally in favour. |
I agree with this idea. It does not make sense to have |
On the heels of #141, we now have that the
Apply
andBind
instances for a data type have to agree when that data type also has aMonad
. It seems like we're still missing something.With the laws as they're written, you can have a
Bind
instance for a data type that doesn't agree with itsApply
instance, so long as said data type does not also define aMonad
instance. I think that's not right. I think we want to make sure that theApply
andBind
instances agree.A real data type that could sneak a lawful
Bind
instance in as the laws are now isData.Validation.Semigroup.V
:I'm pretty sure that definition is associative, but it will "short-circuit" at the first invalid case. That doesn't agree with the
Apply
instance (which accumulates invalid cases).I'm proposing that we change
ap
to something like:And move the
Applicative Superclass
law toBind
(probably change the name of the law as well).Thoughts?
The text was updated successfully, but these errors were encountered: