Re: [GHC] #5462: Deriving clause for arbitrary classes

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Goals: * Save a few characters: say `deriving( C )` rather than `deriving instance C a => C (T a)` * Make it possible for a library author to make a class `C` which can be used in `..deriving( C )` just like built-in classes. * Ultimately: remove the built-in code for deriving `Eq`, `Ord` etc with generic code. Concerns * Conflict between this feature and GND for newtypes. * Current proposal is that this new feature is not available for `newtype`s. * An alternative: a declared property of the class says "do not use GND" in `deriving` clauses. (Examples: `Show`, `Read`, and one or two others.) Maybe we don't even need to make this user-controllable; a handful of built-in classes may suffice. * Another alternative: fail if there ambiguity. * Richard wants it to be a property of the class ''and'' over-rideable at the `deriving` site. * For a top-level instance `instance C a => C (T a)`, this is always an empty instance, filled in by generic defaults if they exist. But what about `deriving instance C a => C (T a)`. Does that mean precisely the same thing? * If you say `data T a = ... deriving( C )`, and change to `data T a = ...; deriving instance C a => C (T a)`, does that make a difference? * Possible principle. Use per-class control for `newtype ... deriving( C )` situation, but per-instance control for `deriving instance` and `instance` declarations. Another question: * Just having one generic default method may not be enough. Maybe two are needed to give a well-founded instance. * Better: class author writes an explicit `MINIMAL` pragma with an empty minimal set. That says, fully explicitly, that the class author is happy with instances that have no explicit methods. * I think we converged on the latter. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5462#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC