Deprecate Foldable for Either

[Edward Kmett]

Sadly, hlint remains fairly (er.. completely?) ignorant of the types of an
expression. It has no idea what is in scope, and just provides
syntax-directed guidance, so hlint isn't the answer here.

That said, there does seem to be a plausible solution available.

I have zero objection to adding {-# POISON #-} pragma that users could
include in their own code that just makes it so that whatever instance is
named inside of it becomes unusable. You could view it as setting up an
ambiguous instance declaration that is currently impossible to write, so
any attempt to use the instance would complain about ambiguous instances
(or preferably about the instance being poisoned and name the source of the
poison).

This would make the status quo the norm, but then you could modify your
custom Prelude or what have you to {-# POISON instance Foldable ((,) e) #-}
and then any code that transitively depended on your Prelude would complain
if it attempted to use that instance.

Such a poison pragma should be sound with respect to GHC's internals. It is
effectively making an extra instance just to cause conflicts later on in
the instance selection process. This is the same as if we had Foldable the
class being defined in one module, the real instance in another, someone's
poison instance in a third, then a fourth module that imports the whole
diamond. Any attempt to use the instance that is defined in two
contradictory ways in that 4th module today will complain.

Folks who care about these instances would then have the choice about
whether to avoid any package that poisoned any instances they cared about,
and folks who fee strongly about this issue would be able to live in a
world where these instances didn't affect any code they wrote and if they
didn't want to turn off users that care about being poisoned, could turn on
the poisoning through cabal flags so that they don't infect their API but
get an opt-in internal consistency check for local compilation.

-Edward Kmett

P.S. The term poison above derives from the C convention of poisoning names
you don't want to see in your code due to safety considerations. e.g. In
GCC you can do so with

#pragma GCC poison printf sprintf fprintf


On Sat, Mar 18, 2017 at 8:51 PM, <amindfv at gmail.com> wrote:

>
>
> > El 18 mar 2017, a las 16:01, Lana Black <lanablack at amok.cc> escribió:
> >
> >> On 18/03/17 19:49, Henning Thielemann wrote:
> >>
> >>> On Sat, 18 Mar 2017, Carter Schonwald wrote:
> >>>
> >>> for what?
> >>
> >> A warning if someone e.g. calls 'length (a,b)', or more generally, if
> >> certain instances are used.
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > Please no. Many of us like our code Wall-clean while still being able to
> > write polymorphic functions. Adding more warnings that are often
> > triggered by correct code (redundant constraints, anyone?) only leads to
> > more headache.
> >
> > You could make that an hlint rule on the other hand.
>
> Can it be a hlint rule? It seems quite difficult to predict that "length"
> will not ever be passed e.g. a 2-tuple in the general case, within hlint.
>
> I would also favor a warning, and happily have -Wall not include it
> (though I'd prefer inclusion).
>
> Tom
>
>
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> 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/20170319/7069e5b8/attachment.html>