Proposal: An issue tracker for better error messages

[jaror]

@Yakushima

You may respond, “Well, it was just a few minutes out of your life. So what?”

I think you are viewing me too antagonistically, I think your suggestion is a good start for a possible improvement.

@Yakushima

“Variable not in scope on the ghci command line: x. If it exists in some module, declare it in the appropriate module declaration.”

I am not sure how a variable can exist in a module without being declared. Do you mean adding it to the export list of that module? I think that is already something that GHC will suggest GHC suggests adding things to the import lists of the current module, not to the export lists of other modules.

@Yakushima

Offer a list of modules in the modules being developed (not the code being loaded from other sources) where that variable may exist. If it doesn’t exist under that variable name in those modules that would be a good thing to say.

This sounds like a decent idea. The scope of the repl can be confusing. Just to make sure I understand it, do you mean showing a list of the modules that are currently being developed and then suggesting that the user can define their variable in one of those modules? I would also add that the user can define that variable in the repl itself. Maybe some way to view the list of variables that have been defined in the repl would also be helpful.

[ketzacoatl]

I don’t disagree with the perspective or motivation to do something about this, however drastic improvements will take some significant time to see through. So in the meantime, I would like to recommend two things:

1. Keep track of errors that tripped you up, the code that produced them, and what you needed to change to fix the issue.
2. Find someone (or multiple) willing to help mentor you, and for which you can call upon to help unblock you when you’ve gotten yourself thoroughly stuck.

On a related topic, it might also help if you spend time on understanding the different ways Haskeller’s structure code, the different language pragmas they use, and otherwise get more familiar with the details of why a particular piece of code is the way that it is. I found these details to be a bit more specific and nuanced than other languages (and due to the terseness, that is not as much about symbol as the code structure and how things are related to each other), and otherwise related to the problem of error messaging not communicating enough.

[Yakushima]

"I am not sure how a variable can exist in a module without being declared.

I wrote “appropriate module declaration” not “appropriate module.” What do you call the part where you write “module whatever ( … ) where …” Is is “module export list”? Anyway, that’s what I meant.

“do you mean showing a list of the modules that are currently being developed and then suggesting that the user can define their variable in one of those modules?”

No, I meant if the variable is declared in one or more modules you’re working on but ghci can’t see any of those, then list the modules where it /could/ see one of the declarations if it was made external/visible. I’m not sure whether this is easy or hard to do. Part of the problem I had with “variable not in scope” is that it implies that the variable exists in the first place. But sometimes you just type the wrong thing – there is no variable with that exact spelling. Maybe you meant “freight” but wrote “freigt” by mistake. There is a pedantic sense in which “variable not in scope” is a more accurate way to say it. After all, what you typed may be declared and visible in some module you simply neglected to include – how can GHC know? But if the symbol tables for each module under development are visible even if not all of the symbols should be, at ghci REPL scope, it should at least be possible to match on them – maybe even fuzzy-match on them for a “Did you mean …?” message.

Anyway, this is not a big deal for me. I just wanted to say that, for a more conventional language, the question of what the error message might mean is not quite as intimidating as it is for Haskell, where people might feel a lot less confident about their usual programmer intuitions, since Haskell violates quite a few of them.

[Yakushima]

@ketzacoatl

Find someone (or multiple) willing to help mentor you, and for which you can call upon to help unblock you when you’ve gotten yourself thoroughly stuck

“Find someone (or multiple) willing to help mentor you, and for which you can call upon to help unblock you when you’ve gotten yourself thoroughly stuck”

I know that would help me go faster, but if acquiring a programming language virtually requires a mentor, I think it’s bad sign about the language. One reason I’m putting effort into the wiki is to help people learn more self-sufficiently, in a few different ways:

(1) comparison to existing language concepts (but also trying to underscore differences insofar as I understand them); I’m still mentally translating “type class” to “sort of like Java multiple inheritance of interfaces,” because that’s what finally worked for me;

(2) pointing as early in the wiki articles as possible to some simple and very concrete uses for abstractions, instead of heading off into more abstraction.

What I did with the “GADTs for Dummies” article is an example of the latter. Whoever wrote that article was clearly trying to get over a hump that perhaps even mentorship couldn’t get him over. He kept getting explanations that were far from obvious. They were just “obvious” to the explainers. So he figured it out himself, somehow. But then his whole article becomes about how to figure it out, not why anyone should try.

I’m not the kind of person who’s very motivated to learn something just to fit into a community. I want to know what the thing can do for me. I want to know why it’s good. If Haskell is going to survive and thrive, it need to sell itself as “Haskell can do X well”, not “Haskell because Haskell.” Better description of how Haskell is good for doing important things is one way. Better error messages are another way: “Haskell because Haskell because . . . Haskell tools help you understand Haskell.”

[ketzacoatl]

@Yakushima

I know that would help me go faster, but if acquiring a programming language virtually requires a mentor, I think it’s bad sign about the language.

I would agree, and that’s why we need help to change that. Thank you for stepping up to contribute!

@Yakushima

One reason I’m putting effort into the wiki is to help people learn more self-sufficiently, in a few different ways:

That is really great! I hope you keep on that and don’t get burned out. I would also recommend checking in with @Kleidukos and seeing where/how you can help with improvements or attention on the missing gaps in Haskell’s “official docs”.

It’s worth noting: You would not be the first to feel or object to the pain (nor the first to get ignored or grumbled at, “just deal with it”), in fact, there’s a pretty long-list of motivated people stepping up to do just this. The main missing piece is continuity, eg there is no single “haskell org” that is taking ownership over the onboarding experience, providing a cohesive documentation, or tooling experience. I believe what you are experiencing is a result of having loosely-affiliated, but highly-coupled projects, across the ecosystem, doing their best to get along, but mostly failing at creating a cohesive, efficient, and pleasant experience for the “layman haskeller” out there. This is a really hard problem to solve

@Yakushima

I’m not the kind of person who’s very motivated to learn something just to fit into a community. I want to know what the thing can do for me. I want to know why it’s good. If Haskell is going to survive and thrive,

Great! I hope you maintain that attitude and help improve Haskell with it. There is a lot of work to be done, that is quite frankly, not-fun, janitorial bs, and the exciting academic stuff is pretty shiny, so just know that you’ll probably be frustrated and at times feel alone trudging thru the desert. IDK what else to do but focus on collaboration, realistic solutions, and consistently working thru the backlog, asking people to join in as we go.

Goodluck!