WideCharr

As a software developer who later got into hardware design, I've always been pretty disappointed with the quality of HDL tools. You get a bit spoiled by the quality of compilers like gcc and clang, and then you run into ridiculously expensive closed-source SystemVerilog compilers that fall apart on valid and obvious code, can't be run in a build farm, and which report cryptic messages for errors. So I've been working on my own open source SystemVerilog compiler / frontend for a while now, and it's nearing 100% completion in terms of language support.

https://github.com/MikePopoloski/slang

Was this at Stevens Tech? I had a Prof Tewksbury there that would have done something just like this.

Going to plug my work on this here: https://github.com/MikePopoloski/slang

At some point I'd like to see it integrated as the frontend to tools like Yosys to get best-in-class SystemVerilog support in open tools.

runevault made a similar point below, and it's pretty valid -- if you're writing a new compiler for a new language, the target is frequently changing and you care most about iteration speed. I've mostly done compiler development for existing languages, which provides a nice fixed target and the "only" challenge is in providing a good experience for end users within that fixed target.

I like the way the various approaches are presented here, though the author briefly mentions a factor which I feel like really short circuits the entire discussion: error messages. Most people readily agree that recursive descent parsers can provide the best possible error messages, which if you're writing a compiler in 2020 seems like it trumps all other considerations (especially considering you can also get the best possible performance via recursive descent).

The static typing of LR is nice, but trading off user experience for developer experience seems like a bad deal.

Interesting that you "don't know" something and would immediately start passing laws about it...