So far the biggest benefit of this approach is th...

# compiler

[Ryan Kay]

So far the biggest benefit of this approach is that it make the Debugging/Testing much easier as I could just step through and find out wherever the problems were. For drawbacks, I think it made the code more verbose, but I'm not typically too worried about that. There's also the potential to have the wrong Type returned in a Pair/Triple, but I'm building it using TDD to captures such problems. Anyways, I'm currently working on the Parser and I am planning to attempt a similar approach to generate the AST from my Tokens.

My question is this: Is there some specific reason why global variables might be preferable for Lexing and Parsing? Might I be making some kind of huge mistake which will bite me down the road in later stages, or is it simply just going to result in a different and possibly more verbose code style? Thank you kindly for any info and perspectives.

If you wanted to have a look at the full source so far, it's here.

[dmitriy.novozhilov]

Any global static state (if it is not some constants) is always bad IMO, because it introduce bugs when you try to run something in parallel (it even may be not parallel compiler itself, but just parallelized tests). And this is true for any program, not just parser/lexer

Also storing all your mutable state in some object/get rid of mutable state at all is good practice beacuse it encapsulated all state in one place instead of spreading it all over the code

And there is no difference in performance between wrok with global state or state in some object

[dmitriy.novozhilov]

P.S. please hide big snippets of code to threads in future

[Ryan Kay]

Thanks for the response @dmitriy.novozhilov. I was particularly concerned with performance since I won't be able to test that easily yet, so this helps a lot.

P.S. please hide big snippets of code to threads in future

Will do, sorry about that!