It's going to be interesting how this series will expand to more complex concepts of interpreter design, such as grammars, AST's etc. To be honest, right now I'

It's going to be interesting how this series will expand to more complex concepts of interpreter design, such as grammars, AST's etc. To be honest, right now I'm thinking the approach taken to teach the basics of parsers and interpreters is detrimental to understanding how these things work in the real world. IMO, it's important to learn about concepts such as regular expressions/finite state machines for lexers, grammars, lookahead, recursive descent, etc. for parsers first, before diving into code and writing a ghetto-lexer and a linear parser with hard-coded rules and trying to build from there. At some point when you really want to parse and interpret Pascal (which is what the first article in the series mentions as the ultimate goal), you will have to forget about everything the naive code did, and throw away all the code, because you're not going to be parsing any 'real' Pascal code the way the toy examples work right now. Not saying this to talk down the author's effort, because it's an interesting topic and I assume all these things will be addressed in later posts. I just wanted to point out to people who want to learn about parsers and interpreters, that the approach the toy interpreter in its current form will not scale to a real interpreter that can parse something like Pascal code.