<div dir="auto"><div>I figured the biggest wins on lazy <= et al would come from ADTs with two constructors with at least one nullary. Bool, Maybe, and [] all qualify.<div dir="auto"><br></div><div dir="auto">And generally, with operations that can potentially be lazy in either argument, the convention is that it's in the first argument.</div><div dir="auto"><br></div><div dir="auto">Also, there is at least one compelling reason for the comparison operators to be lazy. Take the infinite search monad:</div><div dir="auto"><br></div><div dir="auto">newtype Search r a = Search { find :: (a -> r) -> a }</div><div dir="auto"><br></div><div dir="auto">It has an Alt instance for finding the better of two results with a given valuation function:</div><div dir="auto"><br></div><div dir="auto">instance Ord r => Alt (Search r) where</div><div dir="auto"> Search ma <!> Search mb = Search $ \p -> let</div><div dir="auto"> a = ma p</div><div dir="auto"> b = mb p</div><div dir="auto"> in if p a >= p b then a else b</div><div dir="auto"><br></div><div dir="auto">For Search Bool, which uses a predicate as its valuation function, this means that, if p a is True, it doesn't need to evaluate b or p b at all.</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 14:00 David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Even aside from the memory leak potential and the performance degradation from allocation, adding extra tests will degrade performance in typical cases for many types. Comparing against minBound/maxBound isn't always free. For a simple Int comparison, that's an extra compare and conditional jump every time. For such a fundamental operation, that's a big ouch!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 2:53 PM Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank" rel="noreferrer">cma@bitemyapp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space">If one of my applications develops a memory leak because of this potential change, where should I invoice you for the time wasted tracking down & fixing it? My short-term contract rate is $250/hour but I could be argued down to $200/hour.<br><div style="direction:ltr"><br><blockquote type="cite"><div>On May 7, 2020, at 1:00 PM, Sven Panne <<a href="mailto:svenpanne@gmail.com" rel="noreferrer noreferrer" target="_blank">svenpanne@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">Am Do., 7. Mai 2020 um 15:26 Uhr schrieb David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer noreferrer" target="_blank">david.feuer@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I believe this is all about strictness analysis. If these were lazy, then users would have to be very careful to force the lazy arguments when they don't need that laziness to avoid building unnecessary thunks.</div></blockquote><div><br></div><div>This argument holds basically for every potentially lazy function, and I fail to see why comparisons should be special, so this is not really convincing. :-) We have easy ways to make things more strict, but not the other way around.</div><div><br></div><div>In any case, it has historically been the case that the reference implementations in the Haskell language/library report define the strictness of the defined functions, too. Otherwise things could be very surprising, in both ways (too lazy, too strict). Furthermore, the report is *very* explicit about the derived instances: <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18300011.1" rel="noreferrer noreferrer" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18300011.1</a> And (), Bool, ... are defined via deriving: <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009" rel="noreferrer noreferrer" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009</a></div></div></div>
_______________________________________________<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div></blockquote></div><br></div></div>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>