[Haskell-cafe] Ord methods too strict?

[V.Liepelt]

Hi Sven,

[…] section 11.1 [of the Haskell 2010 Report] explicitly states that all derived operations for Eq and Ord are strict in both arguments.

Good idea to look at the Report. Unfortunately it doesn’t give any reasoning as to why this choice was made.

Best,

Vilem


On 2 Jan 2019, at 19:06, Sven Panne <svenpanne at gmail.com<mailto:svenpanne at gmail.com>> wrote:

Am Mi., 2. Jan. 2019 um 15:42 Uhr schrieb Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk<mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>>:
I mean that for any data type

    data E of C1 | C2 | ...

you are preposing that the (<=) of the derived Ord instance would have a
special case for C1.

... and another special case for (>=) for the last enumeration value. And a very special version for one-element enumerations. And what about (<) and (>)? And derived (==) for one-element enumerations? And, and, and... :-P

Putting on the language lawyer hat: The Haskell Report explicitly states that Bool's Ord instance is derived (section 6.1.1), and section 11.1 explicitly states that all derived operations for Eq and Ord are strict in both arguments. Consequently, Implementing Ord for Bool in a lazier way would violate the specification.

I would say that the the way the report specifies this is a good thing: Coming up with special cases is a bad design principle, consistency almost always trumps anything else (the human brain is notoriously small). Furthermore, laziness is not always a good thing, it could lead to space leaks, so e.g. making Bool's Ord operations lazier would definitely make various people very unhappy sooner or later. :-)
_______________________________________________
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190104/030d103d/attachment.html>