I don't think there's any fundamental reason why unboxed fields prevent a Generic instance, as long as we're happy that unboxed values will be re-boxed in the generic representation. It simply seems as if nobody has thought of implementing this. As an example, consider the following hand-written example which works just fine:
{-# LANGUAGE MagicHash, KindSignatures, PolyKinds, TypeOperators, TypeFamilies #-} module GenUnboxed where import GHC.Exts import GHC.Generics import Generics.Deriving.Eq data UPair = UPair Int# Char# instance Generic UPair where type Rep UPair = K1 R Int :*: K1 R Char from (UPair x y) = K1 (I# x) :*: K1 (C# y) to (K1 (I# x) :*: K1 (C# y)) = UPair x y instance GEq UPair test :: Bool test = let p = UPair 3# 'x'# in geq p p Cheers, Andres On Mon, Sep 7, 2015 at 10:02 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: > Unlifted types can't be used polymorphically or in instance > declarations, so this makes it impossible to do something like > > instance Generic Int# > > or store an Int# in one branch of a (:*:), preventing generics from > doing anything in #-land. (unless someone has found a way to hack > around this). > > I would be okay with implementing a generics-based approach, but we'd > have to add a caveat that it will only work out-of-the-box on GHC 8.0 > or later, due to TH's need to look up package information. (We could > give users the ability to specify a package name manually as a > workaround.) > > If this were added, where would be the best place to put it? th-lift? > generic-deriving? template-haskell? A new package (lift-generics)? > > Ryan S. > > On Mon, Sep 7, 2015 at 3:10 PM, Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> Continuing my support of the generics route. Is there a fundamental >> reason why it couldn't handle unlifted types? Given their relative >> paucity, it seems like a fair compromise to generically define lift >> instances for all normal data types but require TH for unlifted types. >> This approach seems much smoother from a maintenance perspective. >> >> On Mon, Sep 7, 2015 at 5:26 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: >>> There is a Lift typeclass defined in template-haskell [1] which, when >>> a data type is an instance, permits it to be directly used in a TH >>> quotation, like so >>> >>> data Example = Example >>> >>> instance Lift Example where >>> lift Example = conE (mkNameG_d "<package-name>" "<module-name>" >>> "Example") >>> >>> e :: Example >>> e = [| Example |] >>> >>> Making Lift instances for most data types is straightforward and >>> mechanical, so the proposal is to allow automatic derivation of Lift >>> via a -XDeriveLift extension: >>> >>> data Example = Example deriving Lift >>> >>> This is actually a pretty a pretty old proposal [2], dating back to >>> 2007. I wanted to have this feature for my needs, so I submitted a >>> proof-of-concept at the GHC Trac issue page [3]. >>> >>> The question now is: do we really want to bake this feature into GHC? >>> Since not many people opined on the Trac page, I wanted to submit this >>> here for wider visibility and to have a discussion. >>> >>> Here are some arguments I have heard against this feature (please tell >>> me if I am misrepresenting your opinion): >>> >>> * We already have a th-lift package [4] on Hackage which allows >>> derivation of Lift via Template Haskell functions. In addition, if >>> you're using Lift, chances are you're also using the -XTemplateHaskell >>> extension in the first place, so th-lift should be suitable. >>> * The same functionality could be added via GHC generics (as of GHC >>> 7.12/8.0, which adds the ability to reify a datatype's package name >>> [5]), if -XTemplateHaskell can't be used. >>> * Adding another -XDerive- extension places a burden on GHC devs to >>> maintain it in the future in response to further Template Haskell >>> changes. >>> >>> Here are my (opinionated) responses to each of these: >>> >>> * th-lift isn't as fully-featured as a -XDerive- extension at the >>> moment, since it can't do sophisticated type inference [6] or derive >>> for data families. This is something that could be addressed with a >>> patch to th-lift, though. >>> * GHC generics wouldn't be enough to handle unlifted types like Int#, >>> Char#, or Double# (which other -XDerive- extensions do). >>> * This is a subjective measurement, but in terms of the amount of code >>> I had to add, -XDeriveLift was substantially simpler than other >>> -XDerive extensions, because there are fewer weird corner cases. Plus, >>> I'd volunteer to maintain it :) >>> >>> Simon PJ wanted to know if other Template Haskell programmers would >>> find -XDeriveLift useful. Would you be able to use it? Would you like >>> to see a solution other than putting it into GHC? I'd love to hear >>> feedback so we can bring some closure to this 8-year-old feature >>> request. >>> >>> Ryan S. >>> >>> ----- >>> [1] >>> http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Lift >>> [2] >>> https://mail.haskell.org/pipermail/template-haskell/2007-October/000635.html >>> [3] https://ghc.haskell.org/trac/ghc/ticket/1830 >>> [4] http://hackage.haskell.org/package/th-lift >>> [5] https://ghc.haskell.org/trac/ghc/ticket/10030 >>> [6] https://ghc.haskell.org/trac/ghc/ticket/1830#comment:11 >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs