Proposal: Lifting to TExpQ

[Michael Sloan]

Cool!  Yeah, the name bikeshedding on typedLift vs liftT is that
"lift" is already too transformer-ey for my taste, and liftT makes it
even moreso.

Also, I realized I mistyped the type of 'lift', it should be 'Lift t
=> t -> Q Exp'.

-Michael

On Sun, Jan 14, 2018 at 12:05 PM, Dan Burton <danburton.email at gmail.com> wrote:
> +1 to Michael's suggestion; that's basically the same thing I would have
> suggested, modulo bikeshedding.
>
> On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan at gmail.com> wrote:
>
> Hmm, I'm not sure about changing the Lift class, there are good
> reasons to leave it the same and good reasons to change as well.
> There is a lot of precedent for providing safe functions which use
> unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
> Also, not much of the TH API uses TExp, just typed splices.  On the
> other hand, it does make the method's type stronger and directly
> suggest more properties.  It may encourage people to use typed splices
> to define manual instances, which I think is good.
>
> I propose a somewhat less breaking change, defining the following:
>
>     class Lift t where
>       typedLift :: t -> Q (TExp t)
>
>     lift :: Lift t => t -> Q t
>     lift = fmap unType . typedLift
>
> The advantage of this is that a lot more code depends on usage of
> 'lift' than defining instances of 'Lift'.  A lot of the code that
> defines instances of 'Lift' does it via the 'th-lift' package.  I
> believe that only a handful of packages would need to be updated as a
> result of this change, vs the dozens that would need to be updated by
> changing the type of 'lift'.
>
> Even after this change, I think that since 'TExp' is only useful with
> typed splices, the 'lift' form would still find much more usage as the
> more convenient function.
>
> -Michael
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>