Hacker News Reader

Comment by saagarjha | Hacker News Reader

And people say theoretical computer science isn’t useful in “the real world”…

I am curious about this one, though, has anyone used it?

> The syntax diagnostics from the compiler made by Sue Graham's group at Berkeley were the mmost helpful I have ever seen--and they were generated automatically. At a syntax error the compiler would suggest a token that could be inserted that would allow parsing to proceed further. No attempt was made to explain what was wrong.

On the surface it sounds a lot like it would produce error messages like “expected ‘;’” that most beginner programmers come to hate: was it any better than this, or was that the extent of its intelligence and everything else at the time was even worse?

View on HN

> On the surface it sounds a lot like it would produce error messages like “expected ‘;’” that most beginner programmers come to hate

Do people really come to hate these? I'd expect the opposite -- that people would start off hating messages like "expected ';'", but fairly quickly become accustomed to what they almost always mean.

As long as you can look at the message and have a good idea of what's wrong, it's not a bad message.

The issue is that the solution to errors like these is often not adding a semicolon, but something else like “the compiler has no idea what is going on in this line” and the actual problem can range from something like an unbalanced delimiter, a misspelled keyword, or even a “syntactically valid-looking” (that a stupid parser, like a code highlighter or formatter, would approve of) but ultimately subtly illegal construct. With practice is usually becomes fairly easy to figure out where the actual error is, but it’s certainly not a very good experience for beginners. (And they’ll “come to hate it” because they’ll see it more than a few times before understanding how to deal with them.)

Pascal grammar is sufficiently different from C-alikes, so it might explain why for Pascal source code these messages are more meaningful.

Elm has syntax errors stylized in this manner, but I am not sure how much is only rephrasing of usual "expected" or something more elaborate

Once you've used a compiler like Rust or Elm that actually provides suggestions for common solutions to these errors (effectively building the tribal knowledge of what the error "really means" into the compiler itself), it's hard to tolerate these cryptic errors that only really make sense to machines.

I'd like to know more about how they do this. Do you know a good source?

I often found Rust's errors completely confusing, even after chasing down the '--explain CrypticNNNNN' follow-up explainer. This was in 2019 — not some ancient version of Rust.

Yeah, Rust’s compiler errors are decent if you make simple mistakes but degrade to being about as bad as any other modern compiler’s once you start doing complicated things. Which isn’t horrible, but --explain isn’t really useful so it’s just wasting space on my screen.

Please file bugs for any message that is confusing! We track them like any other bug, and there’s some folks actively working on them.

Hmm, I wouldn’t call them confusing per se, they’re just not useful, and I don’t think any compiler has really solved this problem (but then again, generation of compiler error messages is not something I’m an expert in). Let’s say I forgot to put a “*” in front of something: the compiler’s error might be something like “xyz does not implement SomeTrait, here is a page explaining what traits are”. I’d be more than happy to file bugs for things like these but I have generally refrained from doing so because I am unsure if this is something that is possible to fix. If you’d like, I could file issues for things like this, but I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area.

Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug.

> I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area.

It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then ship. And then look at the next error.

> Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug.

That's a fantastic attitude and I really appreciate that someone is working towards that goal, thanks.

> It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then ship. And then look at the next error.

Exactly. That person is a saint.

I have no issue with filing bugs about errors I think aren’t great, aside from the fact that I might not be able to suggest anything better…I’ll try it out the next time I see something.

I'll keep that in mind for future interaction with rustc, thanks. Just to double check, you are referring to Github issues on the rust-lang/rust repository, right?

I am!

They were frustrating in pascal because of its original ;-as-separator philosophy. Lightspeed/Think pascal would give you those errors and guide you to a compilable program, but it was still too easy to make that mistake in the first place.

On the other hand, a missing semicolon in Microsoft C would often give a litany of unrelated errors.

Some versions of GCC, as well (like, mid 2000s 3.x or 4.x).

I would guess the most useful part of that is that would allow parsing to proceed further.

I used an Algol compiler that had messages such as:

  Semicolon missing after end (inserted)

  Undeclared identifier ‘foo’ (assumed integer)

Both of these hugely improved the compiler output, as far fewer utterly useless error messages would be produced (yes, I know I didn’t declare ‘foo’. You told me so the previous 12 times I used it)

Parsing valid programs is easy, so are bailing out or going into the woods when encountering invalid syntax. Producing meaningful error messages for line 100 after having seen errors on lines 13, 42 and 78 can be fairly hard.

Couple this with ast and source similarity search (how this is enabled is tbd) would allow one to not only suggest how to complete the program via the compiler's analysis, but then also find code that was similar to your program across all source say in crates.io or on github.

Great learning tool, but also the ability to copy-pasta from terabytes of code ... (scurries off to do some analysis).

MetaWare was producing a C/C++ compiler that did much the same thing, in the 1980s.

I played around with it a bit in college; in my experience, the "help" wasn't very helpful, although it was suggesting keywords and not semi-colons (though I might not have left any out). I don't remember any specific examples, but I think the thing was that it was suggesting syntactically correct things, but they seemed irrelevant compared to the semantics of what I was trying to do.

I think it's interesting that McIlroy was able to learn Pascal from it!

Probably the majority of input validation (compilers or otherwise) errors I see today are still "unexpected x", and I would still often prefer "expected y".

Compilers have gotten significantly better in the past couple years. But in the browser I'm using to write this comment is even worse than "unexpected x", since it gives me the type and not even the token:

    var x = 1 console.log(x + 1)
    SyntaxError: unexpected token: identifier

Reply on news.ycombinator.com