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
Unbiased Semigroup instance for Data.Map.Map #36
Comments
I would be on board without reservation if this were 3 or 4 years ago, but changing the Semigroup instance in this way could very easily break existing code in a way which is only surfaced at runtime. I think we would need to seek community input before doing this. See also #2, which discusses the Semigroup instance (although suggests a different one again). |
Oh right, I thought it would be safe to strenghten the Semigroup instance context by requiring a Semigroup instance for the values but it would be unacceptable for We could deprecate this instance and suggest another for I guess we should rather add an unbiased newtype over maps and document the behaviour of the Semigroup instances for foreign objects and maps like it is done for hash maps then. |
I mean, I'm not saying let's not do it at all. I think it may be worth asking; the fact that Foreign.Object and Map differ in this way is definitely odd and a potential footgun, and I think this instance is arguably more useful; I've definitely wanted this behaviour in a few places before. I just think that approaching the community about it before we do it is probably necessary. |
I'd almost argue that there shouldn't be a default instance, as like in the * Actually, as I was writing this, it occurred to me that if we follow the logic of our |
The argument of following the logic of our Maybe instance is persuasive to me, yeah. Just to check we're on the same page: that line of thinking would suggest that we have |
Yep, that's exactly what I had in mind 👍. Unfortunately this still might be a sneakily breaking change? Perhaps even more so that swapping the append order, since if we change the instance and it just so happens that the |
Yeah, it's definitely a sneakily breaking change, which is why I think we'd need to approach the community: firstly so that people are more likely to be aware, and secondly so that they have an opportunity to object. |
I‘ve proposed in #36 (comment) a strategy to mitigate the risks of this change, at the cost of some churn. We can’t prevent the same program to behave differently when compiled with different versions of the compiler but at least we can guarantee that programs compiling without warnings at v0.x.y still compile without change of behaviour at version v0.(x+1).0 |
We can present that as an option when we suggest this to the community, but honestly I'd prefer to just do it in one go. |
We generally try to avoid cases where programs which continue to compile after a breaking compiler change but behave differently, but I don't think it's something we can guarantee. We do occasionally need to make changes which will cause behaviour changes, e.g. the change to fix sharing in function composition inlining in https://github.com/purescript/purescript/releases/tag/v0.13.0. |
Oh ok, I thought leaving enough time to the ecosystem to adapt and guiding the transition with warnings and errors would make this pill easier to swallow (especially since that change wouldn’t fix any compiler bug). I’ll prepare a post to ask the community! |
Please also consider that some people don't update their code with every release. Someone who jumps multiple major versions at once could miss the deprecation release, and have the same experience as if there hadn't been one at all. |
This is another breaking change release that should be made in Per the Discourse post discussing this issue:
I don't think we should do what was originally described exactly. If we have a In other words:
|
I've opened issues tracking the future breaking changes to make regarding this issue. Closing. |
The Semigroup instance for Data.Map.Map is right-biased, meaning that duplicates are droped from the LHS, but the instance for Foreign.Object.Object requires a Semigroup constraint on its elements type to append duplicates!
We should at least document the difference or either bias the instance for Foreign.Object.Object or unbias the instance for Data.Map.Map.
I believe the behaviour of Foreign.Object.Object to be the most sensible here and would like the Data.Map.Map instance to be unbiased, especially now that we have Coercible.
The following would benefit from type applications, deriving via, constraint kinds and quantified constraints (:upside_down_face:) but is otherwise usable today and allows us to recover the behaviour of the current Semigroup instance for Data.Map.Map with _LeftBiased and the combinators from Data.Newtype (
ala _LeftBiased foldMap
andunder2 _LeftBiased (<>)
for example) given an unbiased instance:The text was updated successfully, but these errors were encountered: