You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2024. It is now read-only.
A default signature in general does not alleviate the user from implementing the corresponding method in instances. They only apply to special situations. Thus, they should not be taken into account when computing the MINIMAL complete definition.
If I think about it, it is probably best to never try to compute the minimal complete definition automatically, but only verbalize the contents of the MINIMAL pragma when it is given.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A
default
signature in general does not alleviate the user from implementing the corresponding method in instances. They only apply to special situations. Thus, they should not be taken into account when computing theMINIMAL
complete definition.E.g., in https://hackage.haskell.org/package/equivalence-0.4.0.1/docs/Data-Equivalence-Monad.html#t:MonadEquiv the "Minimal complete definition" is stated to be
Nothing
because every method has adefault
signature or a conventional default implementation. However, this statement is wrong in the sense that a nakedinstance
will lead to broken code in all cases.If I think about it, it is probably best to never try to compute the minimal complete definition automatically, but only verbalize the contents of the
MINIMAL
pragma when it is given.The text was updated successfully, but these errors were encountered: