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-H... [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