31–40 of 49 posts
Earlier quoted context omitted.
Weren't a lot of functional languages, like ML and it's descendants, created specifically to write parsers and compilers?
I've seen it claimed that ML was originally written, in lisp, in order to have a better language to write compilers in.
Yet another “compiling” course that puts all the emphasis on parsing. Rule of thumb: parsing/lexing shouldn’t takes more than 10% of your compiler course.
Earlier quoted context omitted.
Nice comment, GPT user. Now, GPT: Replace all occurrences of the substring "me" with "you" in the above comment text.
Huh. I don't get those vibes. Further investigation doesn't support your claim. The citations check out, including publication year and publishers. And the author has indeed praised the book many times before ( https://news.ycombinator.com/item?id=31843833 , https://news.ycombinator.com/item?id=31843833 , https://news.ycombinator.com/item?id=31311613 , https://news.ycombinator.com/item?id=28481028 , https://news.ycom…
Yet another “compiling” course that puts all the emphasis on parsing. Rule of thumb: parsing/lexing shouldn’t takes more than 10% of your compiler course.
This attitude bugs me a lot. It seems really common, especially in more recent texts about language design and implementation, that parsing is heavily de-emphasized to the point where practically nobody talks about it. See Essentials of Programming Languages by Friedman & Wand, the relevant sections in SICP, Programming Languages: Application & Interpretation (which goes so far as to call it a distraction). I get tha…
That is definitely true, but in practice there isn't much to say about it, because sophisticated parsers turn out not to be particularly important; it works out better overall to design simple grammars, and then the parsing is easy.
- If you're a beginner, you'll write a recursive descent parser, because that's the simplest technique, and it lets you focus on your project instead of a new, unfamiliar tool.
- If you're writing a domain-specific language, or a config format, or something of that nature, you'll use whichever parser generator integrates most conveniently into your workflow, and you'll design your grammar around whatever its manual tells you to do.
- If you're writing a full-scale language compiler, you'll go back to recursive descent, because that offers the easiest way to recover from errors and report informative messages. Maybe you'll throw in precedence-climbing for operators.
> I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that
I would also read such a book, but it would be more of a book about parser generators than a book about parsers.
Yet another “compiling” course that puts all the emphasis on parsing. Rule of thumb: parsing/lexing shouldn’t takes more than 10% of your compiler course.
This attitude bugs me a lot. It seems really common, especially in more recent texts about language design and implementation, that parsing is heavily de-emphasized to the point where practically nobody talks about it. See Essentials of Programming Languages by Friedman & Wand, the relevant sections in SICP, Programming Languages: Application & Interpretation (which goes so far as to call it a distraction). I get tha…
> I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that
Terrence Parr's "Language Implementation Patterns" spends quite a bit of time on parsing, and parse tree->ast conversyions.
Earlier quoted context omitted.
Huh. I don't get those vibes. Further investigation doesn't support your claim. The citations check out, including publication year and publishers. And the author has indeed praised the book many times before ( https://news.ycombinator.com/item?id=31843833 , https://news.ycombinator.com/item?id=31843833 , https://news.ycombinator.com/item?id=31311613 , https://news.ycombinator.com/item?id=28481028 , https://news.ycom…
For what it's worth, ZeroGPT thinks the comment's a 25%/75% human/AI mix.
The entire comment was 75% human, 46% AI/GPT.
I picked that comment because it had the longest text.
Earlier quoted context omitted.
This attitude bugs me a lot. It seems really common, especially in more recent texts about language design and implementation, that parsing is heavily de-emphasized to the point where practically nobody talks about it. See Essentials of Programming Languages by Friedman & Wand, the relevant sections in SICP, Programming Languages: Application & Interpretation (which goes so far as to call it a distraction). I get tha…
On the other hand, historically (and as the parent you're replying to points out), many compiler texts have spent a MAJORITY of their time on parsing, and rush through the actual interesting parts of compilation. > I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that Terrence Parr's "…
Earlier quoted context omitted.
For what it's worth, ZeroGPT thinks the comment's a 25%/75% human/AI mix.
For what it's worth, ZeroGPT thinks the first paragraph of your comment at https://news.ycombinator.com/item?id=35559453 was "Most Likely GPT generated" (25% written by a human, 100% generated by an AI/GPT). The entire comment was 75% human, 46% AI/GPT. I picked that comment because it had the longest text.
Edit: lmao playing around a bit, simply changing "it is" to "its" (no apostrophe) in the first sentence, and editing the second sentence to read "the problem's that people have to be" makes ZeroGPT no longer think my post was AI generated at all.
Yet another “compiling” course that puts all the emphasis on parsing. Rule of thumb: parsing/lexing shouldn’t takes more than 10% of your compiler course.
Almost all real-world projects that are language-like or compiler-like will need a parser. A much smaller fraction of them will need register allocation, instruction selection, optimization, code generation, etc. For every big, deep, native code compiler, there are a hundred template languages, config files, report generators, etc. all of which are real programs providing real value for actual people. Emphasizing par…
IMHO writing a compiler for a high-level language, in an even higher level language, somehow feels a bit "anachronistic" (for lack of better word).
For what reason?