<div><div dir="auto">I agree with David here. I’m not sure I see a way to have it be usefully lazy? Or even soemthing that we can have be consistently so with any uniformity. Plus could really really mess with certain types of inner loops we’d hope ghc would specialize etc. </div></div><div dir="auto"><br></div><div dir="auto">OTOH I could be totally wrong </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 1:22 PM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Maybe not for everything, but it would hurt `Ord Int` quite a bit.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 12:52 PM Zemyla <<a href="mailto:zemyla@gmail.com" target="_blank">zemyla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">No, it's because automatically derived Ord only defines "compare", which is automatically strict in both arguments because it has to tell EQ from LT or GT. Then the other methods are defined in terms of that. I don't think having (<=) et al be potentially lazy would hurt performance much.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 08:26 David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.<br><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 9:03 AM Simon Jakobi via Libraries <<a href="mailto:libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">libraries@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
Generally, when using libraries, I expect functions to be as lazy as<br>
possible, unless they are documented to have different strictness<br>
properties. My impression was that this rule of thumb is fairly widely<br>
accepted. If this is not a good rule to work with, please do correct<br>
me!<br>
<br>
In any case, I noticed that many instances of Ord in base are an<br>
exception to that rule: (>=), max, etc. tend to evaluate both<br>
arguments, although a result could often be produced based on the<br>
value of only one argument.<br>
<br>
For example (True >= x) could return True without evaluating x, but it doesn't.<br>
<br>
The most blatant and trivial example would be () where the ordering<br>
can be determined without looking at any argument. However:<br>
<br>
$ ghci<br>
GHCi, version 8.10.1: <a href="https://www.haskell.org/ghc/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.haskell.org/ghc/</a> :? for help<br>
> () >= undefined<br>
*** Exception: Prelude.undefined<br>
CallStack (from HasCallStack):<br>
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err<br>
undefined, called at <interactive>:13:7 in interactive:Ghci1<br>
> undefined >= ()<br>
*** Exception: Prelude.undefined<br>
CallStack (from HasCallStack):<br>
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err<br>
undefined, called at <interactive>:14:1 in interactive:Ghci1<br>
<br>
The code where I first noticed the issue looked a bit like this:<br>
<br>
data Const = Type | Kind | Sort deriving (Eq, Ord, Show)<br>
<br>
f :: NonEmpty Const -> Const<br>
f = maximum<br>
<br>
Ideally f would stop traversing the list once it encounters the first<br>
Sort. Yet it doesn't:<br>
<br>
> f (Sort :| [undefined])<br>
*** Exception: Prelude.undefined<br>
<br>
Redefining the Ord instance is trickier than expected too:<br>
<br>
instance Ord Const where<br>
Type <= _ = True<br>
Kind <= Kind = True<br>
Kind <= Sort = True<br>
Sort <= Sort = True<br>
_ <= _ = False<br>
<br>
This is insufficient to fix max, since its default implementation is<br>
biased towards the second argument:<br>
<br>
max x y = if x <= y then y else x<br>
<br>
> max Sort undefined<br>
*** Exception: Prelude.undefined<br>
<br>
So I customize max:<br>
<br>
max Type x = x<br>
max Kind Sort = Kind<br>
max Kind _ = Kind<br>
max Sort _ = Sort<br>
<br>
(f (Sort :| [undefined])) still fails!<br>
<br>
This turns out be due to NonEmpty's Foldable instance relying on the<br>
default definition for maximum:<br>
<br>
maximum :: forall a . Ord a => t a -> a<br>
maximum = fromMaybe (errorWithoutStackTrace "maximum: empty structure") .<br>
getMax . foldMap (Max #. (Just :: a -> Maybe a))<br>
<br>
The problem here is that Maybe's Semigroup instance is strict in both arguments!<br>
<br>
So I have to define<br>
<br>
f = foldr1 max<br>
<br>
…to finally get<br>
<br>
> f (Sort :| [undefined])<br>
Sort<br>
<br>
So my questions are:<br>
<br>
Why are derived Ord instances and most Ord instances in base so<br>
surprisingly strict?<br>
<br>
How come the entire tooling around Ord seems so biased towards strict<br>
Ord implementations?<br>
<br>
Cheers,<br>
Simon<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<br></a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>