4 ms·

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

kkdaemas 5y ago
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
- oauea 5y ago
  > 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?
- phillipcarter 5y ago
  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.
onei 5y ago
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.
mannykannot 5y ago
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.
- duped 5y ago
  What case would introduce a parsing error in an IDE that isn't the case in a compiler?
  - hombre_fatal 5y ago
    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.
    - duped 5y ago
      If the plugins used the same parser as the compiler this wouldn't be an issue?
  - deleted 5y ago
    [deleted]
  - mannykannot 5y ago
    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.

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

oauea 5y ago
> 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?
phillipcarter 5y ago
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.

onei 5y ago

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.

mannykannot 5y ago

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.

duped 5y ago
What case would introduce a parsing error in an IDE that isn't the case in a compiler?
- hombre_fatal 5y ago
  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.
  - duped 5y ago
    If the plugins used the same parser as the compiler this wouldn't be an issue?
- deleted 5y ago
  [deleted]
- mannykannot 5y ago
  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.