Request for comment on new package

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

Request for comment on new package

David Feuer
I've put together a small package for lazifying record types. There's a "classy" version in Data.Lazify and a Generic-only version in Data.Lazify.Generic. A few examples are below. I'd love to hear comments on what looks good and what should be changed before I make the first release. As usual, names are the hardest part. Note especially that the operator ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no operator corresponds to genericLazify. Hrmm mumble.

lazify (1, 2) = (1, 2)
lazify undefined = (_|_, _|_, _|_)
lazify undefined = Sum (_|_, _|_, _|_)

genericLazify (1,2) = (1,2)
genericLazify undefined = (_|_, _|_, _|_)
genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of Lazifiable

lazifyGeneric (1,2) = (1,2)
lazifyGeneric undefined = (_|_, _|_, _|_)
lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)

Thanks in advance,
David

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

Re: Request for comment on new package

David Feuer
Of course, I forgot to actually link to the package candidate. Whoops!
Here it is:


On Tue, Aug 6, 2019 at 3:25 AM David Feuer <[hidden email]> wrote:
I've put together a small package for lazifying record types. There's a "classy" version in Data.Lazify and a Generic-only version in Data.Lazify.Generic. A few examples are below. I'd love to hear comments on what looks good and what should be changed before I make the first release. As usual, names are the hardest part. Note especially that the operator ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no operator corresponds to genericLazify. Hrmm mumble.

lazify (1, 2) = (1, 2)
lazify undefined = (_|_, _|_, _|_)
lazify undefined = Sum (_|_, _|_, _|_)

genericLazify (1,2) = (1,2)
genericLazify undefined = (_|_, _|_, _|_)
genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of Lazifiable

lazifyGeneric (1,2) = (1,2)
lazifyGeneric undefined = (_|_, _|_, _|_)
lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)

Thanks in advance,
David

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

Re: Request for comment on new package

Chris Wong-2
In reply to this post by David Feuer
Hi David,

What are the use cases for such a package?

I'd love to see some examples of problems that can be solved with Lazifiable.

Chris


On Tue, Aug 6, 2019, 19:25 David Feuer <[hidden email]> wrote:
I've put together a small package for lazifying record types. There's a "classy" version in Data.Lazify and a Generic-only version in Data.Lazify.Generic. A few examples are below. I'd love to hear comments on what looks good and what should be changed before I make the first release. As usual, names are the hardest part. Note especially that the operator ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no operator corresponds to genericLazify. Hrmm mumble.

lazify (1, 2) = (1, 2)
lazify undefined = (_|_, _|_, _|_)
lazify undefined = Sum (_|_, _|_, _|_)

genericLazify (1,2) = (1,2)
genericLazify undefined = (_|_, _|_, _|_)
genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of Lazifiable

lazifyGeneric (1,2) = (1,2)
lazifyGeneric undefined = (_|_, _|_, _|_)
lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)

Thanks in advance,
David
_______________________________________________
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: Request for comment on new package

David Feuer
A while back I complained to Ed Kmett that the `Bifunctor` instance for (,) isn't strictly law abiding. Specifically,

  bimap id id _|_ = (_|_, _|_)

while by the first law we should really have

  bimap id id _|_ = _|_

He countered that for some purposes the extra laziness is necessary, and that it's rather less convenient to lazify a pair than to force one (unless you use something like forcePair[*] from utility-ht, which is another one-trick pony to remember). This package is my attempt to prove to Ed that lazifying is almost as easy as strictifying.


On Tue, Aug 6, 2019, 3:55 AM Chris Wong <[hidden email]> wrote:
Hi David,

What are the use cases for such a package?

I'd love to see some examples of problems that can be solved with Lazifiable.

Chris


On Tue, Aug 6, 2019, 19:25 David Feuer <[hidden email]> wrote:
I've put together a small package for lazifying record types. There's a "classy" version in Data.Lazify and a Generic-only version in Data.Lazify.Generic. A few examples are below. I'd love to hear comments on what looks good and what should be changed before I make the first release. As usual, names are the hardest part. Note especially that the operator ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no operator corresponds to genericLazify. Hrmm mumble.

lazify (1, 2) = (1, 2)
lazify undefined = (_|_, _|_, _|_)
lazify undefined = Sum (_|_, _|_, _|_)

genericLazify (1,2) = (1,2)
genericLazify undefined = (_|_, _|_, _|_)
genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of Lazifiable

lazifyGeneric (1,2) = (1,2)
lazifyGeneric undefined = (_|_, _|_, _|_)
lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)

Thanks in advance,
David
_______________________________________________
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: Request for comment on new package

Mario Blažević
In reply to this post by David Feuer
On 2019-08-06 3:29 a.m., David Feuer wrote:
> Of course, I forgot to actually link to the package candidate. Whoops!
> Here it is:
>
> http://hackage.haskell.org/package/lazify-0.1.0.0/candidate

I think lazy would be a better function name than lazify. Generally
speaking, verbs (i.e., actions) should bind to monadic functions.

You put a lot of faith in GHC optimizations. I wouldn't rely on the
default lazify = glazify implementation so much.

Finally, some missing instances from base:

- a -> b
- NonEmpty
- Complex
- Alt
- Par1
- Rec1
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Request for comment on new package

David Feuer
It's not faith; I checked the Core for the instances and found they all optimized properly, and produced optimized unfoldings. Complex has a totally strict constructor, which I think means it shouldn't have a Lazifiable instance. Good point about NonEmpty and the extra newtypes. I've thought about (a -> b), but it's not totally clear to me which instance is best. For consistency, probably

lazify f x = f x

but is that really useful and clear?

I'd be okay with lazy rather than lazify, but that clashes with GHC.Exts.lazy. How bad is that? How would you name the classes and package?

On Sat, Aug 10, 2019, 1:11 AM Mario Blažević <[hidden email]> wrote:
On 2019-08-06 3:29 a.m., David Feuer wrote:
> Of course, I forgot to actually link to the package candidate. Whoops!
> Here it is:
>
> http://hackage.haskell.org/package/lazify-0.1.0.0/candidate

I think lazy would be a better function name than lazify. Generally
speaking, verbs (i.e., actions) should bind to monadic functions.

You put a lot of faith in GHC optimizations. I wouldn't rely on the
default lazify = glazify implementation so much.

Finally, some missing instances from base:

- a -> b
- NonEmpty
- Complex
- Alt
- Par1
- Rec1

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

Re: Request for comment on new package

James Parker
Maybe you can use inspection-testing to add test cases to ensure that these optimizations do not go away in the future. 

On Aug 9, 2019, at 2:40 PM, David Feuer <[hidden email]> wrote:

It's not faith; I checked the Core for the instances and found they all optimized properly, and produced optimized unfoldings. Complex has a totally strict constructor, which I think means it shouldn't have a Lazifiable instance. Good point about NonEmpty and the extra newtypes. I've thought about (a -> b), but it's not totally clear to me which instance is best. For consistency, probably

lazify f x = f x

but is that really useful and clear?

I'd be okay with lazy rather than lazify, but that clashes with GHC.Exts.lazy. How bad is that? How would you name the classes and package?

On Sat, Aug 10, 2019, 1:11 AM Mario Blažević <[hidden email]> wrote:
On 2019-08-06 3:29 a.m., David Feuer wrote:
> Of course, I forgot to actually link to the package candidate. Whoops!
> Here it is:
>
> http://hackage.haskell.org/package/lazify-0.1.0.0/candidate

I think lazy would be a better function name than lazify. Generally
speaking, verbs (i.e., actions) should bind to monadic functions.

You put a lot of faith in GHC optimizations. I wouldn't rely on the
default lazify = glazify implementation so much.

Finally, some missing instances from base:

- a -> b
- NonEmpty
- Complex
- Alt
- Par1
- Rec1
_______________________________________________
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