Proposal: Automatic derivation of Lift

[Thomas Bereknyei]

Yes, I would find DeriveLift useful and a pleasant improvement to the
Template Haskell ecosystem.

I am relatively new to TH and was wondering about a few things (if this
hijacks the thread we can start a new one);

Other quotations,  [m| for 'Q Match' would be helpful to define collections
of matches that can be combined and manipulated. One can use Q
(Pat,Body,[Decl]) but you lose the ability for the Body to refer to a
variable bound in the Pat. One can use Q Exp for just a Lambda, but you
cant just combine lambdas to create a Match expression without some
machinery.

Promotion of a Pat to an Exp. A subset of Pat can create an expression such
that \ $pat -> $(promote pat) is id.

Tom
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 at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150907/42d40e89/attachment.html>