<p dir="ltr"><br>
On Oct 21, 2014 1:22 PM, "John Lato" <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
><br>
> 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.</p>
<p dir="ltr">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?</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>