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
Yes, let's do it. I suggest we make it more like Haskell's "standalone deriving" at first because it will be simpler to implement if the compiler isn't responsible for figuring out what constraints are required. If the feature is able to derive superclasses automatically, in the spirit of #481, then there'll be less boilerplate anyway - e.g. you just write deriving Monoid instead of deriving (Monoid, Semigroup).
User-defined ADTs are implemented as a "newtype" wrapper around an underlying representation of sums and products, so the mechanism for deriving can just look for instances for those representations and adapt them accordingly. Rather than trying to insert appropriate coercions in the method implementations, let's just add another case to DictExpr, DictExpr n = ... | NewtypeDict (DictType n) (DictExpr n). Then when we actually project out the methods in simplification, the newtype coercion becomes a no-op.
Similar to Haskell's
deriving Eq
et al, it would be nice to be able to derive boilerplate type class implementations.See https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/deriving.html
The text was updated successfully, but these errors were encountered: