Re: Avoiding the hazards of orphan instances without dependency problems

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. On Tue, Oct 21, 2014 at 1:22 PM, John Lato 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.

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.

On Tue, Oct 21, 2014 at 9:11 AM, David Feuer wrote:

...

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

{-# InstanceIn Statistics.AesonInstances AesonModule.AesonClass StatisticsType #-}

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. On Oct 21, 2014 11:52 AM, "Stephen Paul Weber" wrote:

...

Somebody claiming to be John Lato wrote:

...

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

{-# OrphanModule ClassName ModuleName #-}

I really like this. It solve all the real orphan instance cases I've had in my libraries.

-- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs