I will say that I asked Shriram Krishnamurti about why books on interpreters and compilers tend to avoid the question of parsing like the plague and found his response a little unsatisfactory.
All these celebrated texts like SICP, EOPL, and Lisp in Small Pieces avoid the question of parsing altogether by focusing on s-expression based languages.
His response was effectively that parsing is over-emphasized in other books, and it's truly orthogonal to other PL activities. Which I can understand, but in practice when I need a parser in my day job I usually don't have much say in the structure of the input "language" (since I'm usually parsing something coming from another source that I have little control over). And it would seem if you have an instructor in a compilers course with this point of view, what other class would give you an opportunity to learn parsing in a formal setting?
A full half of the compilers course I took in undergrad was about {LA,S,}LR; I think "parsing is over-emphasized" is alive and well... That said, it didn't cover non-table-based parsing much. (On the other hand, I'm unaware of a non-table-based parsing algorithm that can statically warn you about problems with the grammar (ambiguities etc).)
Hey, I know Shriram! We were students at Rice together. Not saying we knew each other well, more like passing acquaintances, but I recognize his name.
Anyway, as I recall from compilers classes (it has been ~30 years), the Dragon book heavily emphasized parsing, but the professor said "I'll assign you a parse to do by hand for homework, but and that's it".
The overall attitude was a combo of 1) parsing theory is also covered in another theory of computation class (where the classic textbook was at the time "Introduction to Automata Theory, Languages and Computation" by Hopcroft and Ullman, but these days may also be Sipser's book; 2) there were so many other topics to cover in compilers that a week or so of parsing was all the time budget allowed; and 3) the research focus of the professor's work was in other areas, and compiler research in general was the same.
So not enough attention to parsing might be a side effect (perhaps unfortunate). Even if there is enough material to have an entire class on parsing.
I took the advanced course in compilers too, which was more like a topics class - a research paper every week or so. I don't remember anything about parsing there either.
> why books on interpreters and compilers tend to avoid the question of parsing like the plague
They avoid it like old boring anecdote everyone read yet in their childhood in a dragonbook.
> parsing is over-emphasized in other books, and it's truly orthogonal to other PL activities.
Right, "parsing science" != "compiler science". Parsing science isn't even a subset of compiler science. It's just another discipline which touches (someone may even say overlaps) with it. Consider parsing a natural language. (Which btw any human does, but compiler stuff is surely not for a every human.)
All these celebrated texts like SICP, EOPL, and Lisp in Small Pieces avoid the question of parsing altogether by focusing on s-expression based languages.
His response was effectively that parsing is over-emphasized in other books, and it's truly orthogonal to other PL activities. Which I can understand, but in practice when I need a parser in my day job I usually don't have much say in the structure of the input "language" (since I'm usually parsing something coming from another source that I have little control over). And it would seem if you have an instructor in a compilers course with this point of view, what other class would give you an opportunity to learn parsing in a formal setting?