Warning about certain instances (Was: Add conspicuously missing Functor instances for tuples)

Eric Seidel eric at seidel.io
Wed Feb 17 21:37:36 UTC 2016


This is why I like the forbidden instance idea. It doesn't allow us to
shadow one instance of eg 'Ord Int' with another, it just disables 'Ord
Int' altogether in the current module, thus leaving coherence intact. 

On Wed, Feb 17, 2016, at 13:28, Edward Kmett wrote:
> Sadly Bart,
> 
> Once you do allow explicit qualification of what imports you get you lose
> the global coherence property that we have about the uniqueness of
> instances.
> 
> This isn't just an academic concern. Little libraries like Data.Set cease
> be well behaved, because nothing ensures that the instance you pass to
> the
> call to lookup is the same as was used to build the library. It then
> forces
> you to start carrying all sorts of instances around inside of data, and
> use
> one off methods to manipulate structures rather than use many of the
> classes and tools we can use today.
> 
> Haskell is the only language in wide use that has this property (modulo
> some incoherent instance / orphan instance concerns). It'd be a damn
> shame
> to lose it.
> 
> -Edward
> 
> On Wed, Feb 17, 2016 at 12:38 PM, Bart Massey <bart.massey at gmail.com>
> wrote:
> 
> > IMHO managing import of instances using the normal module import
> > mechanisms is the only sane way to go. I seem to recall SPJ wanting to do
> > this many years ago: I don't remember the details of the discussion or why
> > it wasn't actually done. It does seem hard, but would be so worth it.
> >
> > On Wed, Feb 17, 2016 at 2:30 AM Henning Thielemann <
> > lemming at henning-thielemann.de> wrote:
> >
> >>
> >> On Mon, 18 Jan 2016, Eric Seidel wrote:
> >>
> >> > We might be able to make this work as a type-checker plugin (which would
> >> > be quite nice at least for experimentation). I don't recall off the top
> >> > of my head if the constraint solver calls plugins before or after it
> >> > tries to discharge the constraints on its own, but if plugins get access
> >> > to constraints first we could write one that simply marks undesired
> >> > instances as insoluble.
> >>
> >> Nice to see that you have concrete suggestions how to implement such a
> >> warning. Once I proposed an extension for forbidding certain instances:
> >>    https://ghc.haskell.org/trac/ghc/ticket/7775
> >>
> >> I was forwarded to the "instance chain" proposal that would solve my
> >> problem:
> >>    https://ghc.haskell.org/trac/ghc/ticket/9334
> >>
> >> This ticket also contains a solution that requires only existing
> >> extensions. However this solution does not allow to only warn about a
> >> problematic instance or to prevent the use of such an instance only
> >> locally.
> >>
> >> A proper solution would allow to define a set of forbidden instances and
> >> import that in other packages, but does not affect packages later in the
> >> import chain. A way for explicit import of instances was discussed every
> >> now and then. This might also provide a way to get rid of specific
> >> instances.
> >>
> >>
> >> However, every solution seems to be a long way to go. Eventually, it looks
> >> wrong to me to add security holes first and then start to fix them, or
> >> defer that for an indefinite time.
> >>
> >>
> >> Btw. I see that the problem was already discussed on Reddit:
> >>
> >> https://www.reddit.com/r/haskell/comments/3qcg2d/proposal_forbidden_instances/
> >> _______________________________________________
> >> 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
> >
> >


More information about the Libraries mailing list