Opened 10 years ago

Last modified 7 months ago

#1928 new bug

Confusing type error message

Reported by: josef Owned by:
Priority: low Milestone:
Component: Compiler (Type checker) Version: 6.8.1
Keywords: TypeErrorMessages Cc: claus
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The following code (which is part of a bigger module) needs scoped type variables to compile.

run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
  unit_op v          = (v,s)
  bind_op :: BindOp (StateE s) a (a,s)
  bind_op Get      k = run_state (k s) s
  bind_op (Put s1) k = run_state (k ()) s1

However, forgetting to turn on scoped type variables will give a very confusing error message:

Unimo.hs:56:36:
    Couldn't match expected type `s1' against inferred type `s'
      `s1' is a rigid type variable bound by
           the type signature for `bind_op' at Unimo.hs:55:28
      `s' is a rigid type variable bound by
          the type signature for `run_state' at Unimo.hs:52:22
    In the first argument of `k', namely `s'
    In the first argument of `run_state', namely `(k s)'
    In the expression: run_state (k s) s

Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better.

Change History (5)

comment:1 Changed 10 years ago by simonpj

Milestone: _|_
Priority: normallow

Yes indeed. It's tricky to even formulate what a good error message might be!

I'll leave this open, in case others can see a way to give a better message.

Simon

comment:2 Changed 9 years ago by claus

Cc: claus added

I now seem to be running into similarly sub-optimal type error messages more and more often. My first suggestion for improving these messages would be to include full types for the expressions mentioned in the error context (here: bind_op, run_state, k, s, (k s), run_state (k s) s). That is nearly always the information I'm looking for in these incidents, and it is slightly frustrating that GHC's type error messages elide most of this information - there is too much focussing, not enough context (or rather, the context is type-free, in terms of expressions and source references).

If that makes default error messages too long, I'd be happy with a flag (-verbose-type-errors), possibly with numeric levels (0: current behaviour; n: n levels of contexts are type annotated, context beyond that remains type-free as now).

possibly related: #2360

comment:3 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:4 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:5 Changed 7 months ago by simonpj

Keywords: TypeErrorMessages added
Type of failure: None/Unknown
Note: See TracTickets for help on using tickets.