<div dir="ltr"><div>+1,ideally, th-orphans would be essentially empty for newer GHCs (and so just be a compatibility shim for also getting the instances with older TH)<br></div><div><br></div>Actually, oddly enough, th-orphans ought to not be broken by this.  Other than a number of Lift instances for numeric types, here's how it defines all its Lift instances:<div><br></div><div><div>$(reifyManyWithoutInstances ''Lift [''Info, ''Loc] (const True) >>= <span style="line-height:1.5">deriveLiftMany)</span></div><div><br></div><div>This recursively derives Lift for every datatype transitively, but only if they don't already have a Lift instance.  I'd been hoping to use this for everything in th-orphans, but unfortunately older versions of TH don't support standalone deriving.</div></div><div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 22, 2015 at 5:59 PM Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>+1 from me. Now that it's so easy, I think Lift should be instanced for all concrete types exported from the boot libraries. Do make sure to communicate with the authors of th-lift and th-orphans at some point, though.</div><div><br></div><div>Richard</div></div><div style="word-wrap:break-word"><br><div><div>On Sep 22, 2015, at 10:12 AM, Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div>The DeriveLift extension has landed in GHC HEAD, so now it's become apparent that the bikeshed needs a new coat of paint. The only Lift instances at the moment are base types [1], but with DeriveLift, it would be possible to implement Lift for many for data types with ease.<br><br></div>I'll make (what I hope is) an uncontroversial first suggestion: we should derive Lift for every data type in the template-haskell library itself. These instances have proved to be useful for library authors who need to convert to and from the TH AST (th-desugar, for example, relies on this functionality via orphan instances [2]).<br><br></div>Adding this would break some code out in the wild (the th-lift [3] and th-orphans [4] packages come to mind; there may be others), so I'll request feedback before marching forth with this proposal.<br><div><div><br></div><div>Ryan S.<br></div><div><br>-----<br>[1] <a href="http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Lift" target="_blank">http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Lift</a><br>[2] <a href="http://hackage.haskell.org/package/th-desugar-1.5.4.1/docs/src/Language-Haskell-TH-Desugar-Lift.html" target="_blank">http://hackage.haskell.org/package/th-desugar-1.5.4.1/docs/src/Language-Haskell-TH-Desugar-Lift.html</a><br>[3] <a href="http://hackage.haskell.org/package/th-lift" target="_blank">http://hackage.haskell.org/package/th-lift</a><br>[4] <a href="http://hackage.haskell.org/package/th-orphans" target="_blank">http://hackage.haskell.org/package/th-orphans</a><br></div></div></div>
_______________________________________________<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote></div><br></div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>