Open markhibberd opened 8 years ago
I would be :radio: for this, the fix ups required are pretty mechanical
yeah happy to fix anything that breaks
This came up for me again today! :(
@markhibberd how painful do you think this is likely to be? I'd like to add some1 to P while we're at it.
Oh man, looks like we have the Functor/Applicative/Monad situation all over again. Data.Semigroup is now in base, yet it is not a superclass of Monoid.
how painful do you think this is likely to be?
Not sure, my best guess is probably not that bad, by far most common case is Text
and []
which have instances in both cases. I feel like the most pain will be things break where there are little newtypes in projects where there is GeneralizedNewtypeDeriving on Monoid but people don't do Semigroup. Besides fixing the code all the way up, I can't think of a decent way to avoid just wearing the break.
How's your appetite for forcing upgrades right now? 😆
Stomach-churning.
But... maybe it isn't a bad time. Pretty much everything is up to date from 7.10 / boris sweep. And we will probably do 8 in the next month. Maybe coupling it to 8 roll out?
Doesn't help you right now, but... at least it will be done.
Maybe coupling it to 8 roll out?
Yeah doing it at the same time as 8 sounds good 👍
Doesn't help you right now, but... at least it will be done.
Yeah not too bothered about that as long as it happens eventually.
Just hit this myself when using Megaparsec. Had to do:
import P hiding ((<>))
import Data.Semigroup ((<>))
which is a bit savage. I'm ok with doing this when we switch to ghc 8.0.
Now that X has a more recent optparse which I updated with semigroup instances, this should be easier.
This one is a bit painful and I am not sure there is a perfect answer but I feel like we should probably hide the monoid one and export the semigroup version. Everything in base will work, downside (if you view it as that) is that we probably have code with monoids and no semigroups but would be better if we didn't anyway.