Advanced Compilers: Self-Guided Online Course

Post by pfalcon » Sun, Dec 13, 2020, 2:31 PM UTC

morelisp wrote: post #202

onei wrote: post #152

Earlier quoted context omitted.

Isn't that pretty standard for a parser? When was the last time a compiler bailed on the very first error it hit and refused to do anything else? The solution is to pick synchronisation points to start parsing again, i.e. ; at the end of a statement or } at the end of a block.

> When was the last time a compiler bailed on the very first error it hit and refused to do anything else? Make still does this. (That's the "Stop." in the famous " * missing separator. Stop.") Many errors in Python still do this. As late as 2010 I still saw some major C compilers do this. 99% of the toy compilers written for DSLs do this, or worse. Good error recovery / line blaming is still an active field of devel…

Post by hwabyong » Sun, Dec 13, 2020, 2:43 PM UTC

ibains wrote: post #59

I’ve worked on multiple compilers (optimizations expert) at MSFT on VS and CUDA and gave developed a DSL and worked on Database Compilers. I can’t hire compiler people with right skills. We’re building an IDE and those parsers are written differently, and we use Scala packrat parser combinators. These courses teach very little judgement or industry relevant stuff. When do you use packrat parser vs LALR vs LL? Good lu…

Post by pfalcon » Sun, Dec 13, 2020, 3:07 PM UTC

vector_spaces wrote: post #104

vector_spaces wrote: post #96

Earlier quoted context omitted.

I saw this great interview recently with Anders Hejlsberg at MSFT on how modern compiler construction differs from what is taught in traditional University courses. Is this what you're alluding to? After watching that interview, it's strange to read a comment like yours. While the architecture is completely different, it doesn't frankly seem like that big a leap to go from "senior engineer with X years working on thi…

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 bo…

Post by pfalcon » Sun, Dec 13, 2020, 3:20 PM UTC

munificent wrote: post #161

nialv7 wrote: post #74

Earlier quoted context omitted.

No offence, but parsing (in a compiler, not in general) is probably the most boring part of a compiler. As this is a PhD course, I'd expect the goal of it to be preparing students for research in the field, not writing parsers for some industrial company. Also, there are definitely courses that teach you how to write a parser. But we usually don't call them advanced.

> 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 vomi…

Post by chrisseaton » Sun, Dec 13, 2020, 3:36 PM UTC

pfalcon wrote: post #226

chrisseaton wrote: post #98

Earlier quoted context omitted.

It's pretty hard to pick up compiler skills because very little of it is written down. It takes a lot of time (a few years) working with code bases and papers to absorb it.

> very little of it is written down > and papers to absorb it. I smell a contradiction. But I'm glad that even well-known industry people see it like that. It's not a common flu you can pick up at university library. It's an arcane lore you need to travel faraway to dig into ruins of Library of Alexandria to find the knowledge of.