error-messages
error-messages copied to clipboard
haskell
Very interesting related thread on Twitter
For those interested in the work of this repo, this Twitter thread and its links are worth reading through fully.
https://twitter.com/evincarofautumn/status/1446588940941623296
(I hope it's OK to post this as an issue. "Discussions" might have been more appropriate but this repo does not have it enabled. Feel free to close.)
Compile errors aren’t errors! Most of them are plain outputs with needlessly stern wording.
I would like to see concrete examples of this and suggestions for better wording. Adrian Sieber suggests "type inconsistencies". I think "type mismatch" sounds a bit better. But not all errors are type mismatches, what should the collection be called? Is 'issue' better than 'error'?
Currently, all GHC messages are divided into error or warning, depending on if they block compilation or not. Maybe 'blocking issue' and 'possible issue' are better terms?
I think it might also be nice to show a message at the end of a list of issues: "Stopping due to blocking issues." And then there could be a suggestion: "Use -fdefer-type-errors to continue anyway." if there are only type mismatches.
To me, this isn't as much about the concrete word ("error" vs "issue") but instead the philosophy behind the communication.
That is: are we telling programmers that they have done something wrong? or are we telling them what a good next step would be?
Some of this also relates to what I, as the programmer, am thinking when I check my code. Do I think it's free of type mismatches? If so, then anything GHC detects really is an error: I have erred. On the other hand, if I'm interactively developing my code, I haven't necessarily erred -- I'm just in an unfinished state.
I don't know exactly how it relates, but I feel compelled to share this story: when I was teaching 14-year-olds how to program (that was my day job for 8 years!), we worked with Java in Eclipse. Default settings at the time (and maybe still now) gave red underlines to any error, even as you were typing. Students frequently complained about these errors, because they clearly weren't done with their programs yet. That is, they would type int x = (and that's it) and then see parse errors or other problems -- just because they hadn't got 5; written yet. To some, perhaps these errors were very off-putting -- I'm not sure (I never, say, polled my students on this point in particular).
All of this together almost suggests that we think about two different modes: (1) "GHC, please help me draft this code" vs (2) "GHC, compile this supposedly-correct Haskell into object code". In a sense, -fdefer-type-errors gets us from (2) (the default) to (1). But it does a somewhat poor job of this, because it's not phrased as a switch from (2) to (1) at all.
I wish I had a good sense of what to do with this line of thought. I don't. But I do feel that it should be the IDE's job -- not GHC's -- of dealing with this difference. On the other hand, it's GHC's job to communicate enough detailed information to the IDE so that the IDE can help the programmer effectively. This will happen through structured error messages, etc.
This was a bit of a ramble, but hopefully it will help the next person come up with something more actionable.
This was a bit of a ramble, but hopefully it will help the next person come up with something more actionable.
I thought it was a wonderful comment full of great insights!
To clarify my intent in starting this thread, I certainly don't mean to suggest we should change the word "error" to something else. I posted it mainly to raise awareness that some people consider the compiler to be like an unpleasant opponent. This was a remarkable concept to me when I first came across it (I think I read someone describe a compiler error as "the compiler shouting at him"). I've never felt that way but I think it's important to bear in mind that some fraction of users will.
My students almost universally called the underlines "angry". As in, when they typed int x = and got the red line, they would explain that Eclipse is angry at them. They were 100% aware that a compiler has no emotion and said this somewhat in jest, but I think there is a truth here.
some fraction of users will
From my experiences teaching, I conjecture that this is a very large fraction. Fourteen-year-olds may feel at liberty to say things adults won't admit -- like that getting compiler errors makes them feel the same way that they feel when someone is angry at them and tells them off. Perhaps this emotional response changes as we age, but it also seems possible that what changes is our ability to connect to and/or admit that feeling.
I do add many undefined instead of typed holes, to make the compiler "less angry". In some sense, I somewhat sympathize with 14-year-olds.
