-
Notifications
You must be signed in to change notification settings - Fork 24
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
Behavior of Semigroup/Monoid instances for Prod? #39
Comments
Yes, that behaviour seems more useful than the current one, and it's better to use an established standard behaviour when we can. I can't remember if there's any good reason for the current design, but I don't think so. It was probably just the most obvious monoid I could think of at the time. If we were able to deprecate uses of a type class instance it would be quite reasonable to change them after a deprecation period on the old instances, but I don't think that's possible with GHC right now. Since that's not possible, perhaps we could remove them in a release and reintroduce the new instances after some time? What do you think? Does anyone else have any input? |
why not document it and bump the major version? it seems cleaner than a gap
in the presence of an instance (but I agree that it being misleading as a
non-type-error change is problematic).
…On Wed, Nov 28, 2018, 00:05 Olle Fredriksson ***@***.*** wrote:
Yes, that behaviour seems more useful than the current one, and it's
better to use an established standard behaviour when we can. I can't
remember if there's any good reason for the current design, but I don't
think so. It was probably just the most obvious monoid I could think of at
the time.
If we were able to deprecate uses of a type class instance it would be
quite reasonable to change them after a deprecation period on the old
instances, but I don't think that's possible with GHC right now.
Since that's not possible, perhaps we could remove them in a release and
reintroduce the new instances after some time?
What do you think? Does anyone else have any input?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMbKJEWixdJ14i1T2ZdEVBEMZ_qlvks5uzkPmgaJpZM4Y2sZc>
.
|
Yeah, it's to avoid breaking people's code without compile errors. I'm not sure how careful we need to be here. Are there even any users using the instances in question, and if they are, are they returning results that have Monoid or Semigroup instances? |
|
I would hazard a guess that few people are using those instances, but it's really hard to know. I've got no great insights to add regarding an upgrade path. |
I noticed that the Monoid and Semigroup instances for Prod duplicate the Alternative instance. I found that unexpected. I was expecting them to lift the element instances over the Applicative instance, a la
(<>) = liftA2 (<>)
. That's the behavior of those instances in many other parsing libraries.Changing the instances now would be awkward, of course. People might not see the change and think that just because their grammars still compile, the code still is correct. I'm not really asking for a change. Just wondering why this design was chosen, and suggesting that a change is something you might consider if you ever make large-scale changes that would break things in other ways.
The text was updated successfully, but these errors were encountered: