31–37 of 37 posts
I fail to see the mystery. In my opinion, state machines are the most straight-forward parts of programming. There is a learning curve with lex and yacc but if you cannot ever use these programs then what can you really call yourself a programmer? It's the endless search for a "new" programming language and the layers upon layers of needless abstraction created by today's "programmers" that I find mystifying.
Earlier quoted context omitted.
> If you implement a top-down recursive descent parser, you'll quickly learn how it maps to LL. This will indeed tell you how top-down parsers work. But this doesn't tell you very much about LL specifically. The trickiest part of parsing is deciding what path to take. When you hand-write a recursive descent parser, your code for deciding between alternatives is ad hoc. For example if you are parsing JSON you'll have…
The first and follow sets for LL are the first hurdle you'll hit when you try to parse something where the next production (the next path) doesn't consume the token straight away. The theory becomes instantly accessible for practical reasons. So I respectfully disagree. You'll quickly learn there's a mechanical transformation from LL(1) grammars to recursive descent. And if you write a recursive descent parser with o…
How did you like working on Delphi? I wish I had been studying this stuff that early!
I fail to see the mystery. In my opinion, state machines are the most straight-forward parts of programming. There is a learning curve with lex and yacc but if you cannot ever use these programs then what can you really call yourself a programmer? It's the endless search for a "new" programming language and the layers upon layers of needless abstraction created by today's "programmers" that I find mystifying.
using lex and yacc, is not the same thing as knowing how lex and yacc work.
What about Earley's algorithm? Unfortunately, given the extremely limited hardware of 1960s computers (not helped by the lack of an efficient algorithm), the parsing of an arbitrary CFG was too slow to be practical. Parsing algorithms such as LL, LR, and LALR identified subsets of the full class of CFGs that could be efficiently parsed. Later, relatively practical algorithms for parsing any CFG appeared, most notably…
Thanks for the reference. For those like me who'd not heard of it, see [1] for a description and links to many implementations. [1] https://en.wikipedia.org/wiki/Earley_parser
Earlier quoted context omitted.
The first and follow sets for LL are the first hurdle you'll hit when you try to parse something where the next production (the next path) doesn't consume the token straight away. The theory becomes instantly accessible for practical reasons. So I respectfully disagree. You'll quickly learn there's a mechanical transformation from LL(1) grammars to recursive descent. And if you write a recursive descent parser with o…
Sorry for being a bit pedantic about it. People sometimes write hand-written recursive descent parsers and call them LL parsers, which is sorta true at some level, but misses IMO the key ingredient of automatically-constructed parse tables. I may have been a bit over-eager in reiterating this distinction. How did you like working on Delphi? I wish I had been studying this stuff that early!
More generally I learned how to tackle very complex problems under my own steam, even more so than I had as an autodidact. I have no difficulty drilling down to the next level, all the way to the CPU if necessary, if I have a problem, even if I'm starting out at the level of an interpreted language. I currently work on a web app written in Rails / Coffeescript combo; but I can debug MRI if we get an Ruby issue, and I can and have debugged MySQL when we had crashing issues.