Home > database >  Haskell: Coherence rules wrt. external code
Haskell: Coherence rules wrt. external code

Time:12-08

In Rust, I am not allowed (for good reasons) to for example implement libA::SomeTrait for libB::SomeType.

Are there similar rules enforced in Haskell, or does Haskell just sort of unify the whole program and make sure it's coherent as a whole?

Edit: To phrase the question more clearly in Haskell terms, can you have an orphan instance where the class and the type are defined in modules from external packages (say, from Hackage)?

CodePudding user response:

It looks like you can have an orphan instance wrt. modules. Can the same be done wrt. packages?

Yes. In Haskell, the compiler doesn't really concern itself with packages at all, except for looking up which modules are available. (Basically, Cabal or Stack tells GHC which ones are available, and GHC just uses them.) And an available module in another package is treated exactly the same as a module in your own package.

Most often, this is not a problem – people are expected to be sensible regarding what instances they define. If they do define a bad instance, it only matters for people who use both libA and libB, and they should know.

If you do have a particular reason why you want to prevent somebody from instantiating a class, you should just not export it. (You can still export functions with that class in their constraint.)

  • Related