RFC for a change in EmptyDataDecls instance deriving

[Edward Kmett]

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 <hesselink at gmail.com> 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 <ekmett at gmail.com> 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 <hvr at gnu.org>
> 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150716/19c1e429/attachment.html>