Changing (>>) in monad to accept consumable first inputs#356
Changing (>>) in monad to accept consumable first inputs#356saolof wants to merge 1 commit intotweag:masterfrom
Conversation
Currently (>>) has type m () %1-> m b -> m b . This can easily be generalized to (Consumable a) => m a %1-> m b -> m b . This change would make (>>) more similar to the nonlinear prelude and much more ergonomic to work with in effectful code. But it would technically break backwards compatibility for anyone who explicitly implemented (>>) on their types by making it more constraining, since they'd have to revert to using the default impl or sprinkle a consume somewhere.
|
LGTM. |
You're right. To document it here, I think an alternative is to add: So, one would call However, I have no preference either way, I can see how different use cases can choose convenience over explicitness or vice versa. As we have at least your case choosing for convenience, I see no reason choosing the other way :). |
|
Thanks for your interest @saolof ! I prefer having a So I'll insist pretty strongly on not changing the type of |
|
I think that we could close this as soon as #387 is merged. |
Currently (>>) has type m () %1-> m b %1-> m b .
This can easily be generalized to (Consumable a) => m a %1-> m b %1-> m b .
This change would make (>>) more similar to the nonlinear prelude and much more ergonomic to work with in effectful code. But it would technically break backwards compatibility for anyone who explicitly implemented (>>) on their types by making it more constraining, since they'd have to revert to using the default impl or sprinkle a consume somewhere.
As far as disadvantages go, I guess it might also make the library less explicit by adding the implicit consume? So in that sense there may be a tradeoff between ergonomics and being explicit.