<div dir="ltr">One other benefit of multiple files to use a single module name is that it would be easy to separate testing code from real code even when testing internal/non-exported functions.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 1:22 PM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 9:11 AM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">As I said before, it still doesn't solve the problem I'm trying to solve. Look at a package like criterion, for example. criterion depends on aeson. Why? Because statistics depends on it. Why? Because statistics wants a couple types it defines to be instances of classes defined in aeson. John Lato's proposal would require the pragma to appear in the relevant aeson module, and would prevent *anyone* else from defining instances of those classes. With my proposal, statistics would be able to declare</p>
<p dir="ltr">{-# InstanceIn Statistics.AesonInstances AesonModule.AesonClass StatisticsType #-}</p>
<p dir="ltr">Then it would split the Statistics.AesonInstances module off into a statistics-aeson package and accomplish its objective without stepping on anyone else. We'd get a lot more (mostly tiny) packages, but in exchange the dependencies would get much thinner.</p><div><div>
<div class="gmail_quote">On Oct 21, 2014 11:52 AM, "Stephen Paul Weber" <<a href="mailto:singpolyma@singpolyma.net" target="_blank">singpolyma@singpolyma.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Somebody claiming to be John Lato wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thinking about this, I came to a slightly different scheme.  What if we<br>
instead add a pragma:<br>
<br>
{-# OrphanModule ClassName ModuleName #-}<br>
</blockquote>
<br>
I really like this.  It solve all the real orphan instance cases I've had in my libraries.<br>
<br>
-- <br>
Stephen Paul Weber, @singpolyma<br>
See <<a href="http://singpolyma.net" target="_blank">http://singpolyma.net</a>> for how I prefer to be contacted<br>
edition right joseph<br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>