<p dir="ltr">That makes sense.</p>
<div class="gmail_quote">On Jul 16, 2015 9:11 AM, "Erik Hesselink" <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Eq Void instance is very useful for structures with a type<br>
parameter instantiated to Void. You might still want to compare these<br>
for equality, but that needs an Eq instance for Void.<br>
<br>
Erik<br>
<br>
On Thu, Jul 16, 2015 at 3:10 PM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
> I still don't understand why these instances exist, except maybe to write<br>
> (Proxy :: Proxy p)==(Proxy :: Proxy q) instead of the more usual [Proxy ::<br>
> Proxy p, Proxy :: Proxy q] to force p~q. I'll admit it looks pretty, but it<br>
> seems a bit silly. The Void instance doesn't even have this dubious benefit.<br>
><br>
> Why would one ever want to tie a knot in Void? That violates the entire<br>
> purpose of the type--communicating the idea that it's not supposed to be<br>
> inhabited (btw, I think there is a sensible argument for making Await in<br>
> machines strict in its request argument so that a SourceT is truly incapable<br>
> of awaiting; I don't know how that would affect efficiency though).<br>
><br>
> The efficiency argument only makes sense if one accepts that the code in<br>
> question is sane to begin with. If someone writes disgusting code, I don't<br>
> care if it's compiled well.<br>
><br>
> On Jul 16, 2015 8:29 AM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
>><br>
>> I'd caution against randomly changing Eq and Ord for Void to be less<br>
>> defined in the ill-considered name of consistency.<br>
>><br>
>> We rather deliberately made them as "defined as possible" back in 2012<br>
>> after a very long discussion in which the pendulum swung the other way using<br>
>> a few examples where folks tied knots with fixed points to get inhabitants<br>
>> of Void and it was less consistent to rule them out than it was to define<br>
>> equality on _|_ to be True.<br>
>><br>
>> I'd challenge that nothing is gained by making these combinators strict 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>
</blockquote></div>