Is "in the first argument of..." etc in type error messages useful?

Learn
1

To pick a random example in the scrollback:

src-lib/Foo.hs:296:3: error: [GHC-83865]
    • Couldn't match type: [[RestTable]]
                     with: ExceptT RestProblem m [RestTable]
      Expected: t0 [[RestTable]] -> ExceptT RestProblem m [RestTable]
        Actual: t0 [[RestTable]] -> [[RestTable]]
    • In the first argument of ‘(<$>)’, namely ‘concat’
      In the first argument of ‘($)’, namely
        ‘concat <$> forLimitedConcurrentlyEIO 10 _scDatasets’
      In the expression:
        concat <$> forLimitedConcurrentlyEIO 10 _scDatasets
          $ getTablesForDataSetViaInformationSchema _scConnection
    • Relevant bindings include
        getTablesFast :: BigQuerySourceConfig
                         -> ExceptT RestProblem m [RestTable]
          (bound at src-lib/Foo.hs:295:1)
    |
296 |   concat <$> 
    |   ^^^^^^

I mean we already have the token and line number right there at the bottom. I’m not sure I’ve ever read that “relevant bindings include…” section either. Also sometimes these sections are really huge IIRC

Just thought I’d post here before raising a proposal or trying to just open a PR.

3 Likes
2

It’s probably fine to remove In the first argument of […] In the expression: […], but in that case I’d want to capture more lines of context at the bottom.

The Relevant bindings section sometimes contains important clues, like the providence of key type variables.

1 Like
3

I’d want to capture more lines of context at the bottom.

Help me understand why? For me the context is in my editor window I’ve alt-tabbed away from…

4

The error could come from one of many positions in many files, and is not necessarily visible without me going looking for it. I’d rather have enough context to understand the issue before I decide whether or not to do so.

5

It’s good in a different development mode, when you’re using typed holes trying to piece together something difficult and then the bindings in scope and their types lets you piece together that puzzle. But I’d agree in your particular example, you just want to know what the offending code and don’t care about the rest.

Edit: yes, @jberryman I meant the relevant bindings. Saves me adding a comment to say “yes”.:grin:

6

By “it” you mean the “relevant bindings include…” section? (The “In the Nth argument of …” section doesn’t have types, it’s just an english language description of the syntactic structure surrounding the error afaiu)

1 Like
7

+1. Since we have the exact expression highlighted at the bottom, I think we can get rid of the first bullet entirely and add more to Relevant bindings:

src-lib/Foo.hs:296:3: error: [GHC-83865]
    • Couldn't match type: [[RestTable]]
                     with: ExceptT RestProblem m [RestTable]
      Expected: t0 [[RestTable]] -> ExceptT RestProblem m [RestTable]
        Actual: t0 [[RestTable]] -> [[RestTable]]
    • Relevant bindings include
        concat :: t0 [[RestTable]] -> [[RestTable]]
        (<$>) :: (t0 [[RestTable]] -> ExceptT RestProblem m [RestTable])
                         -> ExceptT RestProblem m (t0 [[RestTable]])
                         -> ExceptT RestProblem m [[RestTable]]
        getTablesFast :: BigQuerySourceConfig
                         -> ExceptT RestProblem m [RestTable]
          (bound at src-lib/Foo.hs:295:1)
    |
296 |   concat <$> 
    |   ^^^^^^
8

I look at relevant bindings messages a lot, as it allows you to see where the typechecker first had the wrong type.

1 Like
9

In case any readers don’t know (it is not well documented):

8 Likes
10

Thank you for mentioning those flags. I will start using them at once. I find almost all the stuff in the type error messages totally useless.

Also, I dislike that one type error gives me many type error messages at different locations. I’d prefer just one (which, sadly, sometimes is not the first one). Compiler, just give up after the first type error!

1 Like
11

Maybe you want to use -fno-keep-going

12

I should finish the patch that fixes it, thank you for reminding me ^^

3 Likes
13

That would be easy to achieve. Would anyone like to volunteer to do the work?

1 Like
14

For some errors it’s fine to keep going, e.g., undefined identifier. But for type errors, GHC seems to have a hard time to “synchronize" again.

15

Would that be at odds with this tech proposal, or is it a different issue?

16

I take it Use -fno-show-error-context from GHC 9.8 by dsaenztagarro · Pull Request #4295 · haskell/haskell-language-server · GitHub means HLS will eventually do that by default?

4 Likes
17

Seems so, yep. No need for context when you’re already hovering over the line in question.

2 Likes
18

Yes. It’s a bit of a shame that that has stalled. It really shouldn’t be hard in principle.

More generally, what we actually need is for someone to finally migrate the core of HLS to use structured diagnostics, instead of all the horrific string manipulation that is currently going on. These were added a few GHC versions ago, but I suspect it’s an awful lot of work to move everything over. Plus there’s a lot of potential for bikeshedding exactly what information should be shown in the editor. Hopefully it could be done gradually.

1 Like
19

Do you mean --diagnostics-as-json? Because that doesn’t even separate the context from the error message.

20

No.

HLS uses GHC-the-library, and that library now represents errors and warnings as a proper ADT rather than effectively as strings. But HLS still only knows how to deal with the strings, so since the ADTs were added, it just prints them and tries to parse the results.

See this post on the GHC feature and the relevant HLS issue.

1 Like