Re: RFC for a change in EmptyDataDecls instance deriving

Well, things made *im*possible: you can't do silly things like use Voids as keys in a map, or look for Voids in a list, as that will expose the Voids for the lies that they are. But you're right, I doubt this is a very common use case. I guess it just feels wrong to me to consider 'let x = x in x' be equal to 'error "boo"'. It also fits with all other functions on Void, which, when receiving an argument, use something like 'absurd' on it to produce their answer. Which leads to another oddity: given 'v :: Void', if 'v == v = True', what about something like 'absurd v :: Int == absurd v'? That would be bottom, which again, seems weird to me. Note that I have no great arguments and no intention of breaking anyone's code, quite the opposite. So I'd be very interested to see if/how defining the Void Eq instance to return True can be benificial. Erik On Thu, Jul 16, 2015 at 6:33 PM, Edward Kmett wrote:

Do you have an example of a thing made possible by making them more strict? =)

-Edward

-Edward

On Thu, Jul 16, 2015 at 9:10 AM, Erik Hesselink wrote:

...

Do you have an example of things made possible by the version returning True?

Erik

On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett wrote:

...

I'd caution against randomly changing Eq and Ord for Void to be less defined in the ill-considered name of consistency.

We rather deliberately made them as "defined as possible" back in 2012 after a very long discussion in which the pendulum swung the other way using a few examples where folks tied knots with fixed points to get inhabitants of Void and it was less consistent to rule them out than it was to define equality on _|_ to be True.

I'd challenge that nothing is gained by making these combinators strict in their arguments.

-Edward

On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel wrote:

...

On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:

...

It's all a bit weird. I think the Proxy instance is lazy too. I would tend to think that empty types shouldn't have these instances, and that if they do that should be strict (empty case), but I can't prove that's the right way.

Btw, something similiar came up for deepseq, regarding NFData instances for types only inhabited by ⊥ (and the issue of H2010 forbidding instance auto-derivation for constructor-less types was mentioned too):

https://github.com/haskell/deepseq/pull/1#issuecomment-61914093

-- hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries