[GHC] #10598: DeriveAnyClass and GND don't work well together
GHC
ghc-devs at haskell.org
Fri Jul 3 02:27:18 UTC 2015
#10598: DeriveAnyClass and GND don't work well together
-------------------------------------+-------------------------------------
Reporter: osa1 | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.11
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by goldfire):
It sounds to me, from the original summary, that GHC is behaving as
documented, with the exception of a poor choice of error message. Fixing
the error message is one way forward. But -- if you're keen on this sort
of thing -- what would be even better is to come up with a way for users
to direct GHC in this matter.
GHC now has 3 distinct ways of `deriving` classes: the built-in way
(extended beyond Haskell 2010 by various extensions), the GND way, and the
!DeriveAnyClass way. In your example, they are '''all''' applicable (at
least with `-XDeriveFunctor` on). And, I believe they will each produce
different instances! What I've wanted here is to have some way to control
GHC's choice of `deriving` mechanism, per instance. Something like
{{{
newtype MyMaybe a = Mk (Maybe a)
deriving( {-# GND #-} Functor
, {-# BuiltIn #-} Show
, {-# GND #-} Read
, {-# Any #-} FromJSON )
}}}
Now, the user chooses what facility provides the instances. Note that I've
done something currently impossible: I've used GND for the `Read` class.
Normally, we don't want this behavior, and (to my knowledge) there's no
way to convince GHC to use GND to derive a `Read` or `Show` instance. But
maybe some user out there does want it.
This, of course, needs to be extended to standalone-deriving, and all the
details (particularly, what are the default choices for the `deriving`
mechanism) need to be worked out. If you (or anyone else) wants to have a
go at this, I'd happily lend a hand.
Or, if you're not ready to tackle feature design, we'd gladly welcome a
patch just to fix the (clearly broken) error message originally reported.
Thanks!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10598#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list