Re: Request for comment on new package

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. [*] http://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Tuple-Lazy.ht... On Tue, Aug 6, 2019, 3:55 AM Chris Wong 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 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries