Proposal: Lifting to TExpQ

[Emil Axelsson]

Hi!

I wasn't able to find a function like this anywhere:

liftT :: Lift a => a -> TExpQ a
liftT = unsafeTExpCoerce . lift

It seems like a nice addition that would reduce the need for
`unsafeTExpCoerce` in user code.

Should it be added?

/ Emil

[Emil Axelsson]

Ah, yes. That's more than I could take on now, but sounds like the right
way to do lifting.

/ Emil

Indeed. Moreover there is nothing unsafe about this, so I'd like to see this done without using unsafe-anything.
To do this, the Lift class would need to change, from
class Lift t where
lift :: t -> Q Exp
to
class Lift t where
lift :: t -> Q (TExp t)
This would take a bit of work, but it looks to me as if it would be a Good Thing.
Maybe someone could write up a design?
Simon
| -----Original Message-----
| Emil Axelsson
| Sent: 12 January 2018 10:48
| Subject: Proposal: Lifting to TExpQ
|
| Hi!
|
|
| liftT :: Lift a => a -> TExpQ a
| liftT = unsafeTExpCoerce . lift
|
| It seems like a nice addition that would reduce the need for
| `unsafeTExpCoerce` in user code.
|
| Should it be added?
|
| / Emil
| _______________________________________________
| Libraries mailing list
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
| askell.org%2Fcgi-
| bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsof
| t.com%7C3f68f4551f724d2d8cfa08d559a9f13b%7C72f988bf86f141af91ab2d7cd01
| 1db47%7C1%7C0%7C636513508787847030&sdata=FUvPD77GrLn%2Bkc3ZUwfinQacU8p
| s00oXFvfI6VhoD1Q%3D&reserved=0

[Michael Sloan]

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

[Dan Burton]

+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" <***@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

[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

Post by Dan Burton
+1 to Michael's suggestion; that's basically the same thing I would have
suggested, modulo bikeshedding.
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries