Ord methods are surprisingly strict

David Feuer david.feuer at gmail.com
Thu May 7 18:59:39 UTC 2020


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!

On Thu, May 7, 2020, 2:53 PM Christopher Allen <cma at bitemyapp.com> wrote:

> 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.
>
> On May 7, 2020, at 1:00 PM, Sven Panne <svenpanne at gmail.com> wrote:
>
> Am Do., 7. Mai 2020 um 15:26 Uhr schrieb David Feuer <
> david.feuer at gmail.com>:
>
>> 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.
>>
>
> 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.
>
> 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:
> https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18300011.1 And
> (), Bool, ... are defined via deriving:
> https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009
> _______________________________________________
> 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/20200507/d4893415/attachment-0001.html>


More information about the Libraries mailing list