Ord methods are surprisingly strict

[Christopher Allen]

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/45611acd/attachment.html>