Proposal: liftData for Template Haskell

[Edward Kmett]

I'm very much +1 to the addition of liftData, but pretty strongly -1 on the
notion of using an overlappable instance for Data a => Lift a. I really
don't like encouraging that practice, orphans then start changing behavior
in ways that make me deeply uncomfortable.

On the other hand, placing a default signature:

class Lift a where
  lift :: a -> Q Exp
  default lift :: Data a => a -> Q Exp
  lift = liftData

would be something I'd be 100% behind, in addition to adding the explicit
liftData export.  It'd rather sharply reduce the pain of defining Lift
instances and I was actually surprised it wasn't there.

-Edward

On Wed, May 13, 2015 at 2:28 AM, Gershom B <gershomb at gmail.com> wrote:

> On May 13, 2015 at 2:15:26 AM, Ganesh Sittampalam (ganesh at earth.li) wrote:
> > -1: I think that kind of instance (Foo a => Bar a) is generally quite
> > problematic so there should be a pretty strong case to support it.
> >
> > There can only be one of them - if some other class shows up that can
> > also provide an equally good implementation of 'lift', there's a
> conflict.
> >
> > Also won't people get misleading error messages, implying they should
> > implement Data when Lift would do?
> >
> > "instance Lift X where lift = liftData" doesn't seem too onerous to
> > write by hand to me, though I guess it may be hard to discover that's an
> > option.
>
> 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 :-)
>
> -g
>
> > On 05/05/2015 04:36, Edward Z. Yang wrote:
> > > Hello all,
> > >
> > > It looks like people are opposed to doing with the lift type-class.
> > > So here is a counterproposal: mark the Lift type class as overlappable,
> > > and define an instance:
> > >
> > > instance Data a => Lift a where
> > > ...
> > >
> > > This is fairly desirable, since GHC will sometimes generate a call to
> > > 'lift', in which case liftData can't be manually filled in. People
> > > can still define efficient versions of lift.
> > >
> > > Edward
> > >
> > > Excerpts from Edward Z. Yang's message of 2015-04-17 04:21:16 -0700:
> > >> I propose adding the following function to Language.Haskell.TH:
> > >>
> > >> -- | 'liftData' is a variant of 'lift' in the 'Lift' type class which
> > >> -- works for any type with a 'Data' instance.
> > >> liftData :: Data a => a -> Q Exp
> > >> liftData = dataToExpQ (const Nothing)
> > >>
> > >> I don't really know which submodule this should come from;
> > >> since it uses 'dataToExpQ', you might put it in
> Language.Haskell.TH.Quote
> > >> but arguably 'dataToExpQ' doesn't belong in this module either,
> > >> and it only lives there because it is a useful function for defining
> > >> quasiquoters and it was described in the quasiquoting paper.
> > >>
> > >> I might propose getting rid of the 'Lift' class entirely, but you
> > >> might prefer that class since it doesn't go through SYB (and have
> > >> the attendant slowdown).
> > >>
> > >> This mode of use of 'dataToExpQ' deserves more attention.
> > >>
> > >> Discussion period: 1 month
> > >>
> > >> Cheers,
> > >> Edward
> > > _______________________________________________
> > > Libraries mailing list
> > > Libraries at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> > >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150513/3356eeeb/attachment.html>