Orphans in hidden packages

[zliu41]

buildDictionary filters out orphans from hidden modules:

-- Remove hidden modules from dep_orphans
orphans <- filterM (moduleIsOkay env0) (moduleName <$> dep_orphs (mg_deps guts))

That means if A imports B, B imports C, and C is in a hidden package when compiling A, then I don't think the orphan instances in C will be found by buildDictionary, even though C is transitively imported by A.

I think GHC does consider such orphan instances when resolving type class constraints. I wonder if what buildDictionary does is a deliberate design choice?

[conal]

I probably added that filtering because something visibly broke without it. GHC is a complicated beast, and it's been a few years now, and so I'm afraid I don't remember my motivation.

How did you come upon this question?

[zliu41]

We use the concat plugin at Kitty Hawk and I noticed that it doesn't always find the orphan instances.

I tried removing the filter and got errors like

      Could not load module `Data.Colour'
      It is a member of the hidden package `colour-2.3.5'.

So I guess that's the reason for having it, but I wonder if there's a better solution (like somehow making GHC suppress this error).

[conal]

Thanks for the additional context. That error message certainly rings a bell for me! I’m afraid that my plugin is using GHC in ways its authors didn’t anticipate. Although the GHC API is several years old now, it’s still much younger than GHC itself, and so there are probably contradictions between the implementation’s assumptions and the offered flexibility of the API.

I vaguely remember struggling with orphan instances, including some GHC calls or parameters especially for those instances. Hopefully the flexibility is there but I simply didn’t exercise it correctly. I encourage you to give it a try if you have the needed combination of will, stamina, and know-how. (Luck may help, too.)