Avoiding the hazards of orphan instances without dependency problems

David Feuer david.feuer at gmail.com
Tue Oct 21 18:22:20 UTC 2014


On Oct 21, 2014 1:22 PM, "John Lato" <jwlato at gmail.com> wrote:
>
> Perhaps you misunderstood my proposal if you think it would prevent
anyone else from defining instances of those classes?  Part of the proposal
was also adding support to the compiler to allow for a multiple files to
use a single module name.  That may be a larger technical challenge, but I
think it's achievable.

You are right; I definitely did not realize this. What happens when files
using the same module name both define instances for the same class and
type(s)? I don't know nearly enough about how these things work to know if
there's a nice way to catch this. Could you explain a bit more about how it
would work? Also, what exactly would be in scope in each of these? Would
adding a file to the module necessitate recompilation of everything
depending on it?

> I think one key difference is that my proposal puts the onus on class
implementors, and David's puts the onus on datatype implementors, so they
certainly are complementary and could co-exist.

Mine puts the onus on either, actually, to support both the pattern of a
maintainer maintaining a class with instances and of one maintaining a type
with instances. To a certain extent these could even be mixed. For example,
a module in base could delegate a number of instances of a certain class,
but we wouldn't want pragmas relating to Hackagy types in there.

One nice thing about my approach is that any program that's correct *with*
the pragma is also correct *without* it—it's entirely negative. In
particular, if someone should come up with a broader/better/ultimate
solution to the orphan instance problem, the pragma could just go away
without breaking anything. Something using multiple files to define one
module inherently requires more support from the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141021/baccd68a/attachment.html>


More information about the ghc-devs mailing list