#7346: Allow the use of `deriving` for GHC generics
---------------------------------+------------------------------------------
Reporter: kosmikus | Owner: dreixel
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.7
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Old description:
> Currently, a class that makes use of generic default methods (via the
> `DefaultSignatures`) extension can be instantiated by providing an empty
> instance declaration.
>
> I propose to allow the use of `deriving` as well:
>
> (1) Standalone deriving should be usable for a class not only for the
> specific set of classes supported by GHC now, but in addition for any
> class, if (A) there's at least one generic default given for a method of
> the class, and (B) there are generic or normal default implementations
> for *all* methods of the class.
>
> There are a number of advantages of this solution over the empty instance
> declaration: we make it explicit that something generic is going on here;
> we ensure at compile time that we're not missing an implementation of a
> method; and we come syntactically closer to built-in derivable classes.
>
> In cases where a conflict arises between current GHC semantics and the
> proposed semantics (for example, when newtype-deriving is involved, I
> guess), I propose to stick with current GHC semantics, but I'm open for
> other suggestions.
>
> (2) I'd also like for normal `deriving` to be useful under the same
> conditions as above. For normal `deriving` GHC has to figure out the
> class context automatically. I propose that if normal `deriving` is used,
> GHC uses the same heuristic for figuring out the class context that it
> uses for `Eq` in the case of `*`-kinded classes, and for `Functor` in the
> case of `* -> *`-kinded classes. That may not be optimal or even wrong.
> But in such cases, standalone deriving can still be used.
New description:
Currently, a class that makes use of generic default methods (via the
`DefaultSignatures`) extension can be instantiated by providing an empty
instance declaration.
I propose to allow the use of `deriving` as well:
1. Standalone deriving should be usable for a class not only for the
specific set of classes supported by GHC now, but in addition for any
class, if (
* there's at least one generic default given for a method of the
class, and
* there are generic or normal default implementations for *all*
methods of the class.
There are a number of advantages of this solution over the empty instance
declaration: we make it explicit that something generic is going on here;
we ensure at compile time that we're not missing an implementation of a
method; and we come syntactically closer to built-in derivable classes.
In cases where a conflict arises between current GHC semantics and the
proposed semantics (for example, when newtype-deriving is involved, I
guess), I propose to stick with current GHC semantics, but I'm open for
other suggestions.
2. I'd also like for normal `deriving` to be useful under the same
conditions as above. For normal `deriving` GHC has to figure out the class
context automatically. I propose that if normal `deriving` is used, GHC
uses the same heuristic for figuring out the class context that it uses
for `Eq` in the case of `*`-kinded classes, and for `Functor` in the case
of `* -> *`-kinded classes. That may not be optimal or even wrong. But in
such cases, standalone deriving can still be used.
--
Comment:
Some examples of what you have in mind would be useful. Perhaps update
and elabores the
[http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving
Wiki page about generic programming features in GHC]?
But it sounds plausible.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7346#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
