New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve error message mechanism #18
Comments
Concretely, here is what I would like to see: Right now, when you call
I would like to see something like this instead:
I think this checks all the boxes from the checklist in OP. (Except line and column, which is more important for source files. We might want to have it if the REPL script grows to be several lines as well.) |
|
Just stumbled over this excellent blog post, which talks very lucidly about different types of errors/warnings/linting warnings, and their fixes. I really liked the terminology of symptom → diagnosis → treatment plan... and I think that's definitely something to keep in mind when working on error messages for Bel. |
Sanctuary's run-time type checking provides another nice source of inspiration; one that is perhaps a little bit closer in genealogy than Elm. |
I just realized that there are two ways the source code to show in an error message might not exist:
|
Just had another fun one. The error report was
and the actual problem was that I had written The flow of that code is going to end up here, which invokes a virtual function here, which fails with the observed type error here (because |
Another good one. The following code:
Gives this error message:
Because the Of course a remotely decent error message would (a) pinpoint the actual cause to be the This is a "static" error, in the sense that we don't need to run code in order to catch it. |
The
A similar thing (totality, maybe even bounded work in some sense) seems to be true of most macros in bel.bel; maybe all of them. (Scanning through them quickly, the only one I'm not sure about is We can run the macro expansion through an interpreter, one which is instrumented to connect the parts of the generated code that were generated from the macro argument, back to the actual location in those arguments. |
I think we (or at least I, but probably all of us) have a blind spot for how bad this one is. It's not common, but it's bad. To put it into words, yes, getting information about where in the source code the error comes from is of course great, some would argue practically necessary. But the assumption is that it comes from somewhere in the source code. In a language where runnable artifacts can be created dynamically at runtime, this simply does not always hold true. I think when people say "code is data", they might mean any number of things. Here are three possible meanings:
I can use my list-builder library to illustrate my point, by creating a bit of executable code that has no corresponding source code: > (set double (build
(link 'lit)
(link 'clo)
(link nil)
(link '(n))
(link '(* n 2))))
(lit clo nil (n) (* n 2))
> (double 5)
10 The code runs and works. But if I change the > (set double (build
(link 'lit)
(link 'clo)
(link nil)
(link '(n))
(link '(* k 2))))
(lit clo nil (n) (* k 2))
> (double 5)
Error: ('unboundb k) There isn't really any source location we can put this |
Right now when something goes wrong with a function call, the error symbol
'cannot-apply
is emitted. Although this is correct by spec, I'd like us to do better.I'd like to have the following error message:
Ideally this should go for all error messages emitted by spec, but let's start here.
The text was updated successfully, but these errors were encountered: