<div dir="ltr"><div dir="ltr"><div>How would you define Ord on Bools? Like so?</div><div><br></div><div>False <= _ = True</div><div>_ <= y = y</div><div><br></div><div>Note that even with this definition, "undefined <= True = undefined" so strictness is now not symmetric. </div><div><br></div><div>Also, as bool are implemented as just an int of some sort (presumably 0 and 1), the strict definition allows the following implementation in effect:</div><div><br></div><div>x <= y = fromEnum x <= fromEnum y</div><div><br></div><div>Note "fromEnum" here is zero cost, and there is no branch. Checking the left hand branch for false first would require a branch that would possibly hit performance. This probably isn't worth slowing down this function just so it's lazy in it's right argument (but as a gotcha now, still strict in it's left argument).</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 2, 2019 at 10:50 PM V.Liepelt <<a href="mailto:V.Liepelt@kent.ac.uk">V.Liepelt@kent.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The implementation of the Ord instance for Bool is derived<br>
<br>
So my argument would be—doesn’t this mean that we need to do cleverer deriving or at least have a hand-written instance?<br>
<br>
> As for the justification, perhaps it's too much of a special case for only<br>
> one value of an enumeration to compare to undefined without crashing<br>
<br>
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.<br>
<br>
Also it doesn’t seem like a special case: this makes sense for any partially ordered Type with a top and/or bottom element.<br>
<br>
> perhaps it inhibits optimisation opportunities.<br>
<br>
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.<br>
<br>
V<br>
<br>
> On 2 Jan 2019, at 11:37, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2017@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2017@jaguarpaw.co.uk</a>> wrote:<br>
> <br>
> On Wed, Jan 02, 2019 at 09:47:15AM +0000, V.Liepelt wrote:<br>
>> I am surprised to find that `False <= undefined = undefined`.<br>
>> <br>
>> What justifies (<=) to be strict in both arguments?<br>
> <br>
> The implementation of the Ord instance for Bool is derived, as you can see<br>
> here:<br>
> <br>
>    <a href="https://www.stackage.org/haddock/lts-12.1/ghc-prim-0.5.2.0/src/GHC-Classes.html#Ord" rel="noreferrer" target="_blank">https://www.stackage.org/haddock/lts-12.1/ghc-prim-0.5.2.0/src/GHC-Classes.html#Ord</a><br>
> <br>
> As for the justification, perhaps it's too much of a special case for only<br>
> one value of an enumeration to compare to undefined without crashing, and<br>
> perhaps it inhibits optimisation opportunities.<br>
> <br>
> Tom<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>