| 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
Interesting and quite reasonable idea, as an extension to `deriving(Generic)`. Make a ticket? Simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]] On Behalf Of | Andres Loeh | Sent: 08 September 2015 13:00 | To: Ryan Scott | Cc: GHC developers | Subject: Re: Proposal: Automatic derivation of Lift | | 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 <[email protected]> | 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 | > <[email protected]> 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 | <[email protected]> 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/La | >>> nguage-Haskell-TH-Syntax.html#t:Lift | >>> [2] | >>> https://mail.haskell.org/pipermail/template-haskell/2007- | October/000 | >>> 635.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 | >>> [email protected] | >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > _______________________________________________ | > ghc-devs mailing list | > [email protected] | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | _______________________________________________ | ghc-devs mailing list | [email protected] | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
