> No offence, but parsing (in a compiler, not in general) is probably the most boring part of a compiler.
Not if you're writing an IDE. Writing a batch mode parser that takes an entire correct source file and produces an AST is easy. Writing a parser that instaneously handle producing an updating AST while the user is typing in the middle of the program while still allowing semantic analysis to occur and without vomiting out a pile of extraneous errors or giving up entirely is a lot harder.
Phew, how boring! I know compiler people who (apparently) spend their time at dayjobs writing IDEs, then get back home and write books on ol' good "batch mode" processing. Can't wait for them to add a JIT chapter. But imagining they would work instead on "writing IDE" chapter would be rather funny ;-).
You could consider this an observation that writing a batch mode parser is so much easier that I'm comfortable writing a book about it, but I still don't know enough to write about IDE-grade parsers and analyzers.
This thread is so weird. The topic at hand is a compliers course. ibains complains about a desire for qualified IDE developers. It's like complaining that your family doctor isn't an orthopedic surgeon. Why should a compilers course spend the requisite time for these highly specialized IDE algorithms?
Specifically. What part of this course should be removed to make room for IDE-specific algorithms? Or, would an advanced IDE algorithms course (with this course as a prerequisite) be a more sensible approach?
Not if you're writing an IDE. Writing a batch mode parser that takes an entire correct source file and produces an AST is easy. Writing a parser that instaneously handle producing an updating AST while the user is typing in the middle of the program while still allowing semantic analysis to occur and without vomiting out a pile of extraneous errors or giving up entirely is a lot harder.