<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">False <= _ = True</div>
<div class="">_ <= y = y</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">Yeah, that’s what I was thinking (in fact this is how I hit this in the first place—I was using `(<=)` as a quick and dirty logical implication operator and was surprised to hit `undefined` even though the precondition was False!)</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">Note that even with this definition, "undefined <= True = undefined" so strictness is now not symmetric. </div>
</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">Isn’t “asymmetry” the whole point of laziness? Consider `(||)`.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">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>
</div>
</blockquote>
<br class="">
</div>
<div class="">Yes, comparison on constants may happen to be faster on a concrete architecture. Thanks, I hadn’t considered this. However this assumes that both arguments are already evaluated, which of course will require branching unless you happen to know
the second argument at compile time, for which case we might want to have a rewrite rule for the more efficient implementation. But it feels wrong to make architectural considerations leak into the standard library when this isn’t really necessary.</div>
<div class=""><br class="">
</div>
<div class="">V</div>
</div>
</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 2 Jan 2019, at 12:09, Clinton Mead <<a href="mailto:clintonmead@gmail.com" class="">clintonmead@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">How would you define Ord on Bools? Like so?</div>
<div class=""><br class="">
</div>
<div class="">False <= _ = True</div>
<div class="">_ <= y = y</div>
<div class=""><br class="">
</div>
<div class="">Note that even with this definition, "undefined <= True = undefined" so strictness is now not symmetric. </div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">x <= y = fromEnum x <= fromEnum y</div>
<div class=""><br class="">
</div>
<div class="">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 class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Jan 2, 2019 at 10:50 PM V.Liepelt <<a href="mailto:V.Liepelt@kent.ac.uk" class="">V.Liepelt@kent.ac.uk</a>> wrote:<br class="">
</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 class="">
<br class="">
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 class="">
<br class="">
> As for the justification, perhaps it's too much of a special case for only<br class="">
> one value of an enumeration to compare to undefined without crashing<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
> perhaps it inhibits optimisation opportunities.<br class="">
<br class="">
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 class="">
<br class="">
V<br class="">
<br class="">
> On 2 Jan 2019, at 11:37, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2017@jaguarpaw.co.uk" target="_blank" class="">tom-lists-haskell-cafe-2017@jaguarpaw.co.uk</a>> wrote:<br class="">
> <br class="">
> On Wed, Jan 02, 2019 at 09:47:15AM +0000, V.Liepelt wrote:<br class="">
>> I am surprised to find that `False <= undefined = undefined`.<br class="">
>> <br class="">
>> What justifies (<=) to be strict in both arguments?<br class="">
> <br class="">
> The implementation of the Ord instance for Bool is derived, as you can see<br class="">
> here:<br class="">
> <br class="">
> <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" class="">
https://www.stackage.org/haddock/lts-12.1/ghc-prim-0.5.2.0/src/GHC-Classes.html#Ord</a><br class="">
> <br class="">
> As for the justification, perhaps it's too much of a special case for only<br class="">
> one value of an enumeration to compare to undefined without crashing, and<br class="">
> perhaps it inhibits optimisation opportunities.<br class="">
> <br class="">
> Tom<br class="">
> _______________________________________________<br class="">
> Haskell-Cafe mailing list<br class="">
> To (un)subscribe, modify options or view archives go to:<br class="">
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank" class="">
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
> Only members subscribed via the mailman list are allowed to post.<br class="">
<br class="">
_______________________________________________<br class="">
Haskell-Cafe mailing list<br class="">
To (un)subscribe, modify options or view archives go to:<br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
Only members subscribed via the mailman list are allowed to post.</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>