Skip to content

Conversation

@rhendric
Copy link

This appeases the -Wnoncanonical-monoid-instances and -Wnoncanonical-monad-instances warnings. These warnings exist because a future GHC release may treat noncanonical definitions as errors.

See also:
https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return
https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/semigroup-monoid

This appeases the -Wnoncanonical-monoid-instances and
-Wnoncanonical-monad-instances warnings. These warnings exist because a
future GHC release may treat noncanonical definitions as errors.

See also:
  https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return
  https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/semigroup-monoid

instance (Repeat f, Monoid a) => Monoid (Zippy f a) where
mempty = Zippy $ repeat mempty
mappend (Zippy x) (Zippy y) = Zippy $ zipWith mappend x y
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change is potentially changing behavior, so no, I won't do these. Until GHC starts to treat them as errors, I won't cleanup these warnings.

@phadej phadej closed this Feb 23, 2025
@Bodigrim
Copy link

There seems to be some confusion elsewhere about the reasoning here. @phadej's argument seems to be (please correct me if I misunderstood it) that defining mappend = (<>) for Zippy f a is invisible for clients only if mappend = (<>) for the underlying a (both semantically and operationally). The latter will become guaranteed only when mappend stops being a member of Monoid and becomes a synonym for (<>).

@phadej
Copy link
Collaborator

phadej commented Feb 26, 2025

only if mappend = (<>) for the underlying a (both semantically and operationally).

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants