Avoiding the hazards of orphan instances without dependency problems

John Lato jwlato at gmail.com
Sun Oct 19 23:17:13 UTC 2014


Thinking about this, I came to a slightly different scheme.  What if we
instead add a pragma:

{-# OrphanModule ClassName ModuleName #-}

and furthermore require that, if OrphanModule is specified, all instances
can *only* appear in the module where the class is defined, the involved
types are defined, or the given OrphanModule?  We would also need to add
support for the compiler to understand that multiple modules may appear
under the same name, which might be a bit tricky to implement, but I think
it's feasible (perhaps in a restricted manner).

I think I'd prefer this when implementing orphan instances, and probably
when writing the pragmas as well.

On Mon, Oct 20, 2014 at 1:02 AM, David Feuer <david.feuer at gmail.com> wrote:

> Orphan instances are bad. The standard approach to avoiding the orphan
> hazard is to always put an instance declaration in the module that declares
> the type or the one that declares the class. Unfortunately, this forces
> packages like lens to have an ungodly number of dependencies. Yesterday, I
> had a simple germ of an idea for solving this (fairly narrow) problem, at
> least in some cases: allow a programmer to declare where an instance
> declaration must be. I have no sense of sane syntax, but the rough idea is:
>
> {-# InstanceIn NamedModule [Context =>] C1 T1 [T2 ...] #-}
>
> This pragma would appear in a module declaring a class or type. The named
> module would not have to be available, either now or ever, but attempting
> to declare such an instance in any module *other* than the named one would
> be an error by default, with a flag
> -XAllowForbiddenInstancesAndInviteNasalDemons to turn it off. The optional
> context allows multiple such pragmas to appear in the type/class-declaring
> modules, to allow overlapping instances (all of them declared in advance).
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141020/ebfd7639/attachment.html>


More information about the ghc-devs mailing list