Hacker News Reader

Comment by nicoburns | Hacker News Reader

Why don't you want to do the IDE-style parsing in a compiler?

From time to time, I see errors in IDE parsing. It's not a big deal there, but it would be in a compiler or interpreter.

What case would introduce a parsing error in an IDE that isn't the case in a compiler?

Bad language plugins in an IDE can show you this. Sometimes I'll be using a niche language with someone's side-project plugin that has some issues even though it's correct, like when its file-formatter can't parse the code and fails with an error even though it's valid code for the compiler.

If the plugins used the same parser as the compiler this wouldn't be an issue?

I figure it is on account of the desirable situation you describe in your other post not obtaining: in order to satisfy the goals of the IDE, it attempts to go beyond where the compiler parser would stop, as the compiler is more of a batch than a responsive one, and sometimes the IDE gets it wrong. As you say, batch to responsive is the difficult way to go.

In addition, I suppose that there are people hard at work applying ML in tools to help understand incomplete code and mitigate the false positive problem of traditional static analysis. I can imagine probabilistic parsing being useful in this case, but not so much in compiling.

I was a little curious about this too. It's contrary to what I see in the Go and Rust compilers. My understanding was that it's good to have a go at parsing all input if possible so the end-user can batch fix mistakes, but it's unreasonable to expect error checking in post-parsing steps to occur if there are parse errors because the AST is almost certainly incomplete.

That can be desirable but there are a few challenges:

- The compiler code becomes more complicated, making correctness harder

- The compiler might become slower to run

- Introducing new languages features may become harder, again due to code complexity

> The compiler code becomes more complicated, making correctness harder

> Introducing new languages features may become harder, again due to code complexity

It'll be written for IDEs anyway. Might as well reuse if possible, right?

Compiler will get plenty complicated without IDE scenarios, trust me on that one. Slowness is also never really a thing to worry about here, especially because usage patterns in an IDE vs. a batch process are so different. It's almost always the other way around: someone writes something that's completely fine for a batch process but tanks IDE performance.

Reply on news.ycombinator.com