Proposal: Lifting to TExpQ

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Lifting to TExpQ

Emil Axelsson-3
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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Lifting to TExpQ

Haskell - Libraries mailing list
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-----
|  From: Libraries [mailto:[hidden email]] On Behalf Of
|  Emil Axelsson
|  Sent: 12 January 2018 10:48
|  To: Haskell Libraries <[hidden email]>
|  Subject: Proposal: Lifting to TExpQ
|  
|  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
|  _______________________________________________
|  Libraries mailing list
|  [hidden email]
|  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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Lifting to TExpQ

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

/ Emil

Den 2018-01-12 kl. 13:17, skrev Simon Peyton Jones:

> 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-----
> |  From: Libraries [mailto:[hidden email]] On Behalf Of
> |  Emil Axelsson
> |  Sent: 12 January 2018 10:48
> |  To: Haskell Libraries <[hidden email]>
> |  Subject: Proposal: Lifting to TExpQ
> |
> |  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
> |  _______________________________________________
> |  Libraries mailing list
> |  [hidden email]
> |  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
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Lifting to TExpQ

Michael Sloan
In reply to this post by Haskell - Libraries mailing list
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Lifting to TExpQ

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" <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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" <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Lifting to TExpQ

Haskell - Libraries mailing list
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:[hidden email]]
|  Sent: 14 January 2018 22:14
|  To: Dan Burton <[hidden email]>
|  Cc: Simon Peyton Jones <[hidden email]>; Haskell Libraries
|  <[hidden email]>
|  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
|  <[hidden email]> 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" <[hidden email]> 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
|  > [hidden email]
|  >
|  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
|  >
|  >
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries