<div dir="ltr">Voids as a key in a map blow up for different reasons, namely that Data.Map evaluates the key.<div><br></div><div>In any event my experience tends to run to the opposite direction, anything that makes code less defined, forces results that don't need to be forced or passes dictionaries that don't get used is something I tend to worry about as it leads to code that is doing make-work.</div><div><br></div><div>Your attempt at using x == y => f x == f y is compelling on the surface but falls apart when you push on it.</div><div><br></div><div>x == y = True implies f x == f y = _|_ for tons of things, absurd isn't terribly special in this regard.</div><div><br></div><div><font face="monospace, monospace">() == () = True</font></div><div><font face="monospace, monospace">repeat () == repeat () = _|_ </font></div><div><br></div><div>There is a distinction between definitional equality (=) and constructive, testable, equality (==).</div><div><br></div><div>What we really want is x = y implies f x = f y, which holds here. even x == y implies f x = f y, holds here, just not x == y implies f x == f y.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 2:53 PM, Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, things made *im*possible: you can't do silly things like use<br>
Voids as keys in a map, or look for Voids in a list, as that will<br>
expose the Voids for the lies that they are. But you're right, I doubt<br>
this is a very common use case. I guess it just feels wrong to me to<br>
consider 'let x = x in x' be equal to 'error "boo"'. It also fits with<br>
all other functions on Void, which, when receiving an argument, use<br>
something like 'absurd' on it to produce their answer. Which leads to<br>
another oddity: given 'v :: Void', if 'v == v = True', what about<br>
something like 'absurd v :: Int == absurd v'? That would be bottom,<br>
which again, seems weird to me.<br>
<br>
Note that I have no great arguments and no intention of breaking<br>
anyone's code, quite the opposite. So I'd be very interested to see<br>
if/how defining the Void Eq instance to return True can be benificial.<br>
<span class="HOEnZb"><font color="#888888"><br>
Erik<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Jul 16, 2015 at 6:33 PM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
> Do you have an example of a thing made possible by making them more strict?<br>
> =)<br>
><br>
> -Edward<br>
><br>
> -Edward<br>
><br>
> On Thu, Jul 16, 2015 at 9:10 AM, Erik Hesselink <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a>> wrote:<br>
>><br>
>> Do you have an example of things made possible by the version returning<br>
>> True?<br>
>><br>
>> Erik<br>
>><br>
>> On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
>> > I'd caution against randomly changing Eq and Ord for Void to be less<br>
>> > defined<br>
>> > in the ill-considered name of consistency.<br>
>> ><br>
>> > We rather deliberately made them as "defined as possible" back in 2012<br>
>> > after<br>
>> > a very long discussion in which the pendulum swung the other way using a<br>
>> > few<br>
>> > examples where folks tied knots with fixed points to get inhabitants of<br>
>> > Void<br>
>> > and it was less consistent to rule them out than it was to define<br>
>> > equality<br>
>> > on _|_ to be True.<br>
>> ><br>
>> > I'd challenge that nothing is gained by making these combinators strict<br>
>> > in<br>
>> > their arguments.<br>
>> ><br>
>> > -Edward<br>
>> ><br>
>> > On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org">hvr@gnu.org</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:<br>
>> >> > It's all a bit weird. I think the Proxy instance is lazy too. I would<br>
>> >> > tend<br>
>> >> > to think that empty types shouldn't have these instances, and that if<br>
>> >> > they<br>
>> >> > do that should be strict (empty case), but I can't prove that's the<br>
>> >> > right<br>
>> >> > way.<br>
>> >><br>
>> >> Btw, something similiar came up for deepseq, regarding NFData instances<br>
>> >> for types only inhabited by ⊥ (and the issue of H2010 forbidding<br>
>> >> instance auto-derivation for constructor-less types was mentioned too):<br>
>> >><br>
>> >> <a href="https://github.com/haskell/deepseq/pull/1#issuecomment-61914093" rel="noreferrer" target="_blank">https://github.com/haskell/deepseq/pull/1#issuecomment-61914093</a><br>
>> >><br>
>> >> -- hvr<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Libraries mailing list<br>
>> > <a href="mailto:Libraries@haskell.org">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>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>