<div dir="auto"><div>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</div><div dir="auto"><br></div><div dir="auto">lazify f x = f x</div><div dir="auto"><br></div><div dir="auto">but is that really useful and clear?</div><div dir="auto"><br></div><div dir="auto">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?<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Aug 10, 2019, 1:11 AM Mario Blažević <<a href="mailto:mblazevic@stilo.com">mblazevic@stilo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-08-06 3:29 a.m., David Feuer wrote:<br>
> Of course, I forgot to actually link to the package candidate. Whoops!<br>
> Here it is:<br>
> <br>
> <a href="http://hackage.haskell.org/package/lazify-0.1.0.0/candidate" rel="noreferrer noreferrer" target="_blank">http://hackage.haskell.org/package/lazify-0.1.0.0/candidate</a><br>
<br>
I think lazy would be a better function name than lazify. Generally <br>
speaking, verbs (i.e., actions) should bind to monadic functions.<br>
<br>
You put a lot of faith in GHC optimizations. I wouldn't rely on the <br>
default lazify = glazify implementation so much.<br>
<br>
Finally, some missing instances from base:<br>
<br>
- a -> b<br>
- NonEmpty<br>
- Complex<br>
- Alt<br>
- Par1<br>
- Rec1<br>
</blockquote></div></div></div>