Re: Proposal: Lifting to TExpQ
+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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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@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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
I agree too. I've created https://ghc.haskell.org/trac/ghc/ticket/14671 Now all we need is someone to execute on it. Simon | -----Original Message----- | From: Michael Sloan [mailto:mgsloan@gmail.com] | Sent: 14 January 2018 22:14 | To: Dan Burton <danburton.email@gmail.com> | Cc: Simon Peyton Jones <simonpj@microsoft.com>; Haskell Libraries | <libraries@haskell.org> | Subject: Re: Proposal: Lifting to TExpQ | | 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@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@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@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi- | bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Cs | > | imonpj%40microsoft.com%7C1a64d01a0c6141a3e75808d55b9c27dc%7C72f988bf86 | > | f141af91ab2d7cd011db47%7C1%7C0%7C636515648605968445&sdata=%2FsPADsgmpl | > J2zKS3q8oPC4HUwrU7P3VQrutIODMIjsY%3D&reserved=0 | > | >
participants (3)
-
Dan Burton -
Michael Sloan -
Simon Peyton Jones