If I understand your meaning here, the state you are talking about is the context of symbols in the parser. Different context required you to implement different symbols or keywords.

Bison (and most other parsers) can parse only context-free, or CF grammars. This has several important consequences, mostly all good, but it means that any instance of a symbol in the parse tree has the same context (meaning, semantics) as any other instance of that same symbol - none.

This is the problem resolved by Attribute Grammars which I mentioned in another thread. Attribute grammars allow the parser to pass context, or state or semantics up or down the parse tree. So that you can indeed pass state to higher or lower levels with a context-free grammar.

It is a powerful method and actually simple to implement, and Bison handles it easily. To use it you will need a clear understanding of the parse tree concept and abstract syntax tree (AST), but that is pretty much necessary to write a compiler anyway, and not really difficult.

You can get a very short introduction to the idea behind Attribute Grammars from Grune's 1st edition which you probably already have. It can be freely downloaded here. In the PDF version, pages 58 and 59, just a few paragraphs.

That also has the best introduction anywhere to the parse tree and AST concepts.

I have looked down this page and see you have your blog started - excellent! I'll try to provide some additional comment there in a little while.

Thanks for the information. I will take a look at it. But actually, that's not what I mean. Here is a better explanation of what I meant:

At the lower level, there is a concept of a variable. It stays true to the syntax of that language in the way a variable is created and used. In the higher level, there is a concept of a variable matching that concept. You use the "var" keyword to create a variable. It is partially typed and sort of not typed too. Sort of like variables in JavaScript.

To keep track of the state of the variable in the compiler, I have used a Var class for the C++ end, which I've created. I try to update it back and forth whenever possible, so that what happens at run time happens to the Var class at compile time. But it's not always able to synchronize what happens at run time with what happens at compile time.

So I needed to make ways to get what I want to happen at run time to happen at run time as well.

The link just says it's out of print. Neither the first nor second edition can be downloaded as far as I can tell. But maybe that's at some point a book I need. For now, it's okay.

I really don't have a good understanding of ASTs, though I was trying to understand them at one point. Maybe when I complete my first compiler book, I can understand it. I was going only so far, and then back to my tutorials. C is where I left off. I DO have a lethal understanding of C and C++ though...

P.S. - I'm completing tutorials even on what I already know so that I can get better enough to understand more concepts that I don't already know.

I do not understand this at all. WHat do you mean exactly, by "synchronize"? How should runtime state affect the compile time state?

Yes you can download the complete book from that page. Scroll down to the Availability section and click the link for Book Body in the desired format, Postscript or PDF.

If you have not read the first few chapters of that book, then stop whatever else you are doing and work your way through it! An understanding of the topics in the first three chapters is absolutely essential to all forward progress in my opinion.

Found it now.

Read through the first 3 chapters. Didn't understand it all, but I understand more than before. The mathematical concepts lost me.

By "synchronize", I mean that I know when writing it from the kind of code I'm telling it to generate, what effect that will have to the variable at run time. Then if I'm telling it to have one effect on run time, by the code I'm generating, I try as best as I can to mirror it in the state I'm keeping track of for the variable. That is the only way the run time effects the compile time. If this isn't clear enough yet, I will have to start giving you some code to clarify.

I really should complete my entire books on compilers and interpreters. I have one book just on that subject, and now this book on it too. Before I could complete that, I must complete some basic books on the basic languages I'm working with.

I just got bored because I'm studying some new concepts, but some old ones too. I will only continue working on this language without going through more of it for a time period. I can't promise that without that material, it will be as good a form, but I can always rewrite it if I really need to. Depending on how much it's doing what I want it to do will determine whether or not I do this or not. I'll do it on the if it ain't broke, don't fix it basis. But as soon as it's broke, I will fix it.

I'll learn as I go, and use everything I know so far to accomplish what I'm trying to, but not go backwards and write code that isn't up to my best level of understanding. That said, programming is one of the things I'm better at with computers... System administration, I lack on but am catching up because I use programming to do system administration...

I'll be maintaining the blog here, but it's time to quit with this language now for awhile. I will probably need to redesign it because switch (or cswitch) within one another won't work. That means to make it work, I will probably need to understand ASTs and stuff. So I'll do some more studying before I return to coding it. I'll ask somewhere if I need more help with understanding them.