[GHC] #5462: Deriving clause for arbitrary classes

GHC ghc-devs at haskell.org
Fri Oct 3 14:56:04 UTC 2014


#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


More information about the ghc-tickets mailing list