<div dir="ltr">I'm very much +1 to the addition of <font face="monospace, monospace">liftData</font>, but pretty strongly -1 on the notion of using an overlappable instance for <font face="monospace, monospace">Data a => Lift a</font>. I really don't like encouraging that practice, orphans then start changing behavior in ways that make me deeply uncomfortable.<div><br></div><div>On the other hand, placing a default signature:</div><div><br></div><div><font face="monospace, monospace">class Lift a where</font></div><div><font face="monospace, monospace">  lift :: a -> Q Exp</font></div><div><font face="monospace, monospace">  default lift :: Data a => a -> Q Exp</font></div><div><font face="monospace, monospace">  lift = <span style="font-size:12.8000001907349px">liftData</span></font></div><div><br></div><div>would be something I'd be 100% behind, in addition to adding the explicit <font face="monospace, monospace">liftData</font> export.  It'd rather sharply reduce the pain of defining <font face="monospace, monospace">Lift</font> instances and I was actually surprised it wasn't there.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 2:28 AM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On May 13, 2015 at 2:15:26 AM, Ganesh Sittampalam (<a href="mailto:ganesh@earth.li">ganesh@earth.li</a>) wrote:<br>
> -1: I think that kind of instance (Foo a => Bar a) is generally quite<br>
> problematic so there should be a pretty strong case to support it.<br>
><br>
> There can only be one of them - if some other class shows up that can<br>
> also provide an equally good implementation of 'lift', there's a conflict.<br>
><br>
> Also won't people get misleading error messages, implying they should<br>
> implement Data when Lift would do?<br>
><br>
> "instance Lift X where lift = liftData" doesn't seem too onerous to<br>
> write by hand to me, though I guess it may be hard to discover that's an<br>
> option.<br>
<br>
</span>Isn’t this a case where -XDefaultSignatures and -XDeriveAnyClass can make things at least a bit nicer? Of course we still need to document well how to use them, but such instrumentation of the Lift class would at least make it clear that it is “intended” to be used in such a fashion :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
-g<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On 05/05/2015 04:36, Edward Z. Yang wrote:<br>
> > Hello all,<br>
> ><br>
> > It looks like people are opposed to doing with the lift type-class.<br>
> > So here is a counterproposal: mark the Lift type class as overlappable,<br>
> > and define an instance:<br>
> ><br>
> > instance Data a => Lift a where<br>
> > ...<br>
> ><br>
> > This is fairly desirable, since GHC will sometimes generate a call to<br>
> > 'lift', in which case liftData can't be manually filled in. People<br>
> > can still define efficient versions of lift.<br>
> ><br>
> > Edward<br>
> ><br>
> > Excerpts from Edward Z. Yang's message of 2015-04-17 04:21:16 -0700:<br>
> >> I propose adding the following function to <a href="http://Language.Haskell.TH" target="_blank">Language.Haskell.TH</a>:<br>
> >><br>
> >> -- | 'liftData' is a variant of 'lift' in the 'Lift' type class which<br>
> >> -- works for any type with a 'Data' instance.<br>
> >> liftData :: Data a => a -> Q Exp<br>
> >> liftData = dataToExpQ (const Nothing)<br>
> >><br>
> >> I don't really know which submodule this should come from;<br>
> >> since it uses 'dataToExpQ', you might put it in Language.Haskell.TH.Quote<br>
> >> but arguably 'dataToExpQ' doesn't belong in this module either,<br>
> >> and it only lives there because it is a useful function for defining<br>
> >> quasiquoters and it was described in the quasiquoting paper.<br>
> >><br>
> >> I might propose getting rid of the 'Lift' class entirely, but you<br>
> >> might prefer that class since it doesn't go through SYB (and have<br>
> >> the attendant slowdown).<br>
> >><br>
> >> This mode of use of 'dataToExpQ' deserves more attention.<br>
> >><br>
> >> Discussion period: 1 month<br>
> >><br>
> >> Cheers,<br>
> >> Edward<br>
> > _______________________________________________<br>
> > Libraries mailing list<br>
> > <a href="mailto:Libraries@haskell.org">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>
> ><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">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>
><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">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>
</div></div></blockquote></div><br></div>