Documentation and compiler errors

[adamConnerSax]

I just migrated an mtl-style codebase to Effectful. It was largely straightforward and the codebase is better for it.
Since I was able to add multiple State effects instead of a single effect with a larger state, I did. But then I had various issues when usage of one of those states was ambiguous, indicated by an "Overlapping Instances" ghc error. I sorted them out, but it took me a while to catch on that the "Overlapping instances" error message was indicating that. I wonder if it would be worthwhile to add a section to the readme with some common confusing error messages and what they likely mean?

[arybczak]

Yeah, the overlapping instance error is pretty terrible. Adding it to the documentation is definitely worthwhile, but I also wonder if GHC could deal with this better. Maybe I'll file a ticket on the GHC issue tracker.

[adamConnerSax]

Or is it the sort of thing you can intercept with the TypeError machinery and produce a better error message?

[ocharles]

Does the new Unsatisfiable constraint let us write some better type errors for these cases?

[arybczak]

Custom type errors won't help here.

Basically, there are two cases:

xxx1 :: State Int :> es => Eff es ()
xxx1 = do
  get
  pure ()

here you get

tests/StateTests.hs:21:3: error: [GHC-39999]
    • Could not deduce ‘State a0 :> es’ arising from a use of ‘get’
      from the context: State Int :> es
        bound by the type signature for:
                   xxx1 :: forall (es :: [Effect]). (State Int :> es) => Eff es ()
        at tests/StateTests.hs:19:1-36
      The type variable ‘a0’ is ambiguous
...

this one I would say is not that bad, it explicitly tells you that the type parameter of State in get is ambiguous.

But there's also this:

xxx2 :: Eff '[State Int] ()
xxx2 = do
  get
  pure ()

and then you get

tests/StateTests.hs:28:3: error: [GHC-43085]
    • Overlapping instances for State a0 :> '[State Int]
        arising from a use of ‘get’
      Matching instance:
        instance (e :> es) => e :> (x : es)
          -- Defined in ‘Effectful.Internal.Effect’
      Potentially matching instance:
        instance [overlapping] e :> (e : es)
          -- Defined in ‘Effectful.Internal.Effect’
      (The choice depends on the instantiation of ‘a0’
       To pick the first instance above, use IncoherentInstances
       when compiling the other instance declarations)

I think this is the main subject of complaint here, right? On the other hand, the error message is completely right, it can't pick the instance of :> because the choice depends on the instantiation of a0 in State from get. You just need to read all of it and be familiar with the error already, which is unfortunate (and the hint about incoherent instances is, as 99% of the time, a red herring).

[adamConnerSax]

Yes, the latter error is what I first found very opaque and then learned to basically just skim to find the type parameter ghc was finding ambiguous (usually the one with a number at the end!) and figure out how to make it less so. I don't think it's a problem once you get used to it, though it could obviously be simpler. But it's a little terrifying the first few times! Which is why I suggested documenting it, perhaps along with some hints for how to interpret the message and resolve the error. And yes, the IncoherentInstances bit adds to the confusion...