Proposal: Automatic derivation of Lift

Ryan Scott at
Mon Sep 7 20:02:45 UTC 2015

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

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
<matthewtpickering at> 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 < at> 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]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at

More information about the ghc-devs mailing list