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 : 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-183000...
And
(), Bool, ... are defined via deriving:
https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries