#9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I like this, and think the second set of output reads much, much better. Bonus points: use ANSI terminal colors to highlight some key words in the output, such as "Warning" or "Error" should they exist. Lennart also makes an observation about the way the Mu Haskell compiler handles this: https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_begin... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Here's an error that a noob making a subtle typo might get from GHC: {{{ Prelude> map 1 [1..5] <interactive>:2:1: Could not deduce (Num (a0 -> b)) arising from the ambiguity check for ‛it’ from the context (Num (a -> b), Num a, Enum a) bound by the inferred type for ‛it’: (Num (a -> b), Num a, Enum a) => [b] at <interactive>:2:1-12 The type variable ‛a0’ is ambiguous When checking that ‛it’ has the inferred type ‛forall a b. (Num (a -> b), Num a, Enum a) => [b]’ Probable cause: the inferred type is ambiguous }}} I wholeheartedly agree that the information needs to be presented in a way that's easier to digest. For what should be a really simple error, I really have to stare that down to understand what it's actually trying to say ... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: This seems like a nice and easy ticket to handle by a newcomer. The function to change is `misMatchMsg` in `compiler/typecheck/TcErrors.hs`. Don't forget to update the expected test output. Use 'make accept', see [wiki:Building/RunningTests/Updating]. Please make sure you get all of them (grep for the old error message). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: newcomer => Comment: Yes, I don't think this is easy, precisely for the reasons described in that post. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by chreekat): thomie, that gets to the root of my problem with the message precisely! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I wonder if it would help at all to just reverse the order of the two, that is, {{{ Couldn't match actual type ‘[Char]’ with expected type ‘Int’ In the expression: "Howdy!" }}} Presumably the programmer has a strong association between the expression and its (actual) type, and then can work out what "expected type" refers to by elimination. I'm also not that attached to the phrase "expected type". We could be more explicit and say something like "type ‘Int’ expected from context". I think the phrase "actual type" is quite good, though. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by chreekat): {{{ Foo.hs:4:7: Couldn't match expected type ‘Int’ with actual type ‘[Char]’ In the expression: "Howdy!" In an equation for ‘foo’: foo = "Howdy!" }}} This example reminded me that sometimes the phrase "In the expression" is confusing to me. It seems that the phrase *should* be "Of the expression". Using 'in' makes me expect that the error message is referring to some particular component of the expression, rather than the whole thing. It's a small incongruence, but it's big enough to force me to stop thinking about code and start thinking about the possible meanings of the error message. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Again discussed in this thread: https://www.reddit.com/r/haskell/comments/3tm3lv/proposal_expectedactual_req... Not much new. `expected/found` instead of `expected/actual` seems a popular choice. I vote for switching the order as well, mentioning the word "context", and perhaps omitting the word `actual`. Something like this: {{{ Couldn't match type ‘Char’ with type ‘Bool’ expected from context. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I'd like to have a look. What is the proposed message? Should we use the original message below? {{{ Foo.hs:2:20 inferred: "Just 5" has type "Maybe a0" expected: second argument of "($)" must have type "Int" in the expression: addThree $ Just 5 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I would love to look into this, but it is unclear what the new message is supposed to be. Should we go with the suggestion of the original post, or one of the other rewording suggestions? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): I agree with bgamari too.\\ Well, I glanced at the Oxford Dictionary. I have compared the words "context" and "signature".\\ Here is the definition of the word "context":\\ - The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.\\ Examples:\\ ‘the proposals need to be considered in the context of new European directives’\\ ‘We are going to be able, within a European context, to be in a more positive position.’\\ ‘This is down to his determination to place current events in a historical context.’\\ ‘For new readers this can be an advantage, but they become disadvantages in contexts of closer study.’\\\\ Synonyms of the word context: circumstances, conditions, surroundings, factors, state of affairs\\ frame of reference, contextual relationship.\\ \\ Here is the definition of the word "signature":\\ - A distinctive pattern, product, or characteristic by which someone or something can be identified.\\ Examples:\\ ‘the chef produced the pâté that was his signature’\\ ‘Changes in population size tend to leave recognizable signatures in the patterns of nucleotide diversity.’\\ ‘This process, called intrinsic catalysis, has a characteristic signature in the exchange time measurements versus pH.’\\ ‘Cells tugged in one direction sent biochemical signals in the opposite direction in the form of a signature pattern of fluorescent light.’\\\\ Obviously, the word signature has a more precise meaning, characterizing a thing and the word context has a broader meaning. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Interesting, but I think this is a separate issue (type error message for list literals). `['a', True]` gets translated to `'a' : (True : [])`, see language spec 3.7. https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-340003.7 So there is no special rule for typing list literals, as the compiler checks the translated code anyway. Or so I thought, but in fact there is: after stating the translation, the standard states that in `[e1, ..., ek]`, "the types of e1 ... ek must all be the same". Is this normative, or just a (redundant) explanation? I do think that compiler (error) messages should use wording from the standard. (So, looking up words in OED does not really help. The committee that wrote the standard already did this.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the time is ripe for this ticket, and it shouldn't be hard. Here are the pieces: 1. Update `TcErrors.mkExpectedActualMsg` to print out the `uo_thing` field of the `TypeEqOrigin` passed in. For example, if we're reporting an actual of `Maybe Int` and an expected of `Bool`, then `uo_thing` might hold `Just 5`. This step can likely be done by changing `msg1` of `mkExpectedActualMsg`. 2. Rip out the special treatment of kinds in `mkExpectedActualMsg`. Other than swapping out the word "kind" for "type", kinds and types should be treated the same. This special treatment is currently there solely to match pre-8.0 behavior. Doing this step should improve the error messages worsened by #14066 and fix, e.g., #14887. Concretely, this step is essentially to remove `msg5` from `mkExpectedActualMsg`. Those two steps, by themselves, would nail this ticket. But Simon and I think we can do better. Currently, the `uo_thing` of a `TypeEqOrigin` tracks the term (or type, during kind-checking) that has the "actual" type. (It's the `Just 5` mentioned in step 1.) However, we can also track the aspect of the context that leads us to expect the "expected" type. For example, this string could be something like "required as the condition of an `if`" or "of the second argument of `($)`" or "of the type used in a type signature". Here are example error messages: Code: `if 'x' then foo else bar` {{{ Type mismatch: `Char' /= `Bool' Actual: `Char' is the type of `'x'' Expected: `Bool` is the type required as the condition of an `if' }}} Code: `not $ 'x'` {{{ Type mismatch: `Char' /= `Bool' Actual: `Char` is the type of `'x'' Expected: `Bool` is the type of the second argument of ($) }}} Code: `foo :: Maybe` {{{ Kind mismatch: `* -> *' /= `*' Actual: `* -> *' is the kind of `Maybe' Expected: `*` is the kind of the type used in a type signature }}} Aren't these just lovely? To do this: 3. Add an `SDoc` field to the `Check` constructor of an `ExpType` (in `TcType`). Then, in every `mkCheckExpType`, supply an appropriate message. Ideally, this message will not mention any types, because there will be no chance to zonk them later. 4. Add a new field `uo_context` to `TypeEqOrigin` (of type `Maybe SDoc`) that will get the doc from the `Check`. This seems like it will happen in `TcUnify.tcSubTypeDS_NC_O`, but perhaps in other places, too. It's worth checking every place we make a `TypeEqOrigin`. 5. Teach `TcErrors.mkExpectedActualMsg` to use this new info. We could do steps 1-2 separately from 3-5, but given the very large number of error messages one would have to sweep through to do so, it seems best to common these changes up. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): I will give this one a whirl. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): I was able to make some progress on this ticket (screenshot with new error messages: [https://prnt.sc/ktm8u2]). I will keep working on 3-5. Shouldn't take long to finish this part! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): Update: I was able to locate all the places where we make `TypeEqOrigin`. We do this with a help of a smart constructor `mkCheckExpType`. There are around 80-90 places (across 12 modules) where we use it. There is another function `synKnownType` that uses `mkCheckExpType` which has another 25 occurrences. For now I just used dummy text everywhere to be able to compile it. Here you can see more detailed search results for these functions: * `mkCheckExpType` - https://lpaste.net/7745839270543228928 * `synKnownType` - https://lpaste.net/4510196100136697856 I have already changed some of the messages where I was able to infer the context and come up with meaningful explanations. Here is a screenshot of examples from the ticket with new messages - https://prnt.sc/kycm4c, however, some places are tricky so I will probably need more time to spend on them. Right now my plan is the following - I want to come up with all the test cases(programs) that would call all the code parts where we use the above mentioned functions. By doing that, I will slowly weed out all the dummy messages and replace with meaningful ones. As suggested, I am collecting all the notes of my changes. Perhaps, it is a good time to submit a patch to Phabricator? We could proceed with a discussion there and it would be much easier to discuss all the new messages (with line comments). By the way, If someone could code review and help with new messages - that would be greatly appreciated! Thank you. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9173: Improve type mismatch error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): Sorry for the delay - had to face life! I opened MR here: https://gitlab.haskell.org/ghc/ghc/merge_requests/223 I also added a note there that will be converted to a wiki page in the future. Suggestions and comments are welcome! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9173#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler