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ć <mblazevic at stilo.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190810/0cb1e2de/attachment.html>