Disallow orphan instances

[garyb]

We keep talking about this but don't seem to have an issue for it. I'm quite an enthusiastic proponent of disallowing them and not providing an escape hatch either.

Worth discussing too perhaps, what counts as an orphan in the presence of multi-parameter typeclasses? I guess for an instance to not be an orphan it must satisfy either:

1. The instance is declared in the same module as its class.
2. At least one of the types appearing in the instance head is declared in the current module.

[paf31]

👍 for no escape hatch.

[puffnfresh]

Hugely important to me 👍

And I'm pretty certain those are the correct rules for enforcing coherency with mutli-parameters 👍

[bbarker]

Sorry for reviving an old thread, but I'd like to understand this issue a bit more. I've been thinking about Scala implicits as a model for clashing instances. In my few years of programming Scala, it has never been much of an issue; Scala has manual import/export ability for implicit values as well (iirc, getting a bit rusty with Scala lately).

Existing (non-orphan) instances could continue to be imported implicitly, but orphan instances would require manual import, or give a compile-time failure otherwise. Which seems like a satisfactory outcome, as it is for conflicting implicit values in the same scope in Scala.

I know @puffnfresh has a lot more experience than me in both Scala and PureScript, though, and I haven't thought a lot about this, so I'm sure I'll learn something! But it would be cool to have that power, without sacrificing safety beyond compilation failure at use-sites, which could be avoided by altering imports.

[hdgarrood]

This gets asked occasionally, and I'm not aware of a solid writeup, so it would probably be good to have one. Quite a lot has already been written about this in the Haskell world too, so that's probably a good place to look. See e.g. https://www.reddit.com/r/purescript/comments/4y0qwf/why_are_orphan_instances_strictly_disallowed/ and https://stackoverflow.com/questions/3079537/orphaned-instances-in-haskell. I also recommend looking at the GHC users' guide, which gives a flavour of how involved these issues can become: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#instance-overlap

I think it's basically to do with coherence: the property that any given type can only have one instance of a given class. This is such a natural property that I suspect we often make use of it without even thinking about it. For instance, Map relies pretty heavily on the assumption that a given type can only have one Ord instance: if you were to somehow construct a Map K V in one module with some Ord K instance in scope, and then try to lookup values in that Map in another module where you had a different Ord K instance in scope, you will end up with lookup returning Nothing when it should be returning Just something, because Map depends on coherence of the Ord instance in use.

Another way of looking at it is this: if we allow orphan instances, we have to work out what to do when we have two different candidates for a particular instance in scope.This is a huge can of worms (this can be seen by googling for the numerous threads, blog posts, and stack overflow questions on the subject). One option is to reject the program entirely, but this isn't great: an upstream library adding an instance can now cause your program to stop compiling. Another is to have the compiler pick the most specific instance, but this is difficult to describe and it still suffers from a similar problem: an upstream library might add a more specific instance than the one you were using with slightly different behaviour, so that your program silently starts using that instance as opposed to the more general one which was being used previously.

[shmish111]

@garyb @hdgarrood instances in purescript have names, why not just use the non-orphan by default and give an option to use a named instance (that's what Idris does for example). I can say that not having an escape hatch for orphan instances is the single biggest waste of my time and damage to the codebase when using purescript. As soon as you want to encode and decode things (which is pretty often given purescript is a browser language) you have to add massive amounts of boiler plate, lots of newtypes, wrapping and unwrapping, etc etc etc. I can see all the arguments against orphan instances but it is really, really, really impractical. On a reasonably large codebase, once every month or so I end up wasting a whole day doing this thankless task and I am forced to make my code less readable and more complicated. An extra newtype and the odd unwrap is not a problem but these add up, our codebase is significantly worse because of it. I know I'm not the only person who has had the same experience.

P.S. I'm not as angry as I sound, purescript is an amazing and highly practical tool 😄

[garyb]

I wonder what it is in our respective codebases/styles of working that makes this a problem for you/others, but something I almost never encounter. 🤔

I think Arbitrary / Coarbitrary instances for quickcheck is the only time it's occurred for me, outside of situations where a missing instance was just an oversight and could be PR'd to the library. I guess you're using classes and datatypes from libraries that don't have an existing relationship with each other, but I'm not sure what those would be?

[puffnfresh]

Lack of orphan instances is one of the best things about PureScript. It's not a problem at all.

[shmish111]

It is intriguing. One problem that hits me is that foreign-generic has no instances for list, set, map and tuple and that makes sense from a library perspective I guess since different encodings make sense in different systems (map and tuple particularly). Newtyping every map and tuple in my domain so that I don't have to write very difficult encode/decode instances means that I then have lots of wrap/unwrap in places that I don't want it. I've just had to do this and there was really a lot of boiler plate, way too much so that it made parts of the code very difficult to read. If my project could have it's own instances for these basic data types and I could specify the instance names then all this would be gone. Since we already have to name instances, from a user perspective having some sort of using syntax would be very comfortable and explicit about the fact that you are overriding the default behaviour.

@garyb what do you do about sending deeply nested maps and tuples over JSON?