Request for comment on new package

[James Parker]

Maybe you can use inspection-testing <https://hackage.haskell.org/package/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 <david.feuer at gmail.com> 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ć <mblazevic at stilo.com <mailto: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 <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
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190809/27824549/attachment.html>