[Haskell-cafe] Ord methods too strict?

[V.Liepelt]

> The implementation of the Ord instance for Bool is derived

So my argument would be—doesn’t this mean that we need to do cleverer deriving or at least have a hand-written instance?

> As for the justification, perhaps it's too much of a special case for only
> one value of an enumeration to compare to undefined without crashing

This is not just about crashing. (I’m using `undefined` as a way of making strictness explicit.) `False >= veryExpensiveComputation` should return `True` immediately without any unnecessary computation.

Also it doesn’t seem like a special case: this makes sense for any partially ordered Type with a top and/or bottom element.

> perhaps it inhibits optimisation opportunities.

That doesn’t seem very likely to me, I would rather think the contrary (see above): doing unnecessary work can hardly make a program run faster.

V

> On 2 Jan 2019, at 11:37, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
> On Wed, Jan 02, 2019 at 09:47:15AM +0000, V.Liepelt wrote:
>> I am surprised to find that `False <= undefined = undefined`.
>> 
>> What justifies (<=) to be strict in both arguments?
> 
> The implementation of the Ord instance for Bool is derived, as you can see
> here:
> 
>    https://www.stackage.org/haddock/lts-12.1/ghc-prim-0.5.2.0/src/GHC-Classes.html#Ord
> 
> As for the justification, perhaps it's too much of a special case for only
> one value of an enumeration to compare to undefined without crashing, and
> perhaps it inhibits optimisation opportunities.
> 
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.