Antelope (formerly "OPIA") - A Polymorphic z80 language

Oh yeah JC, this is it. Since 2004, my mind has been on this topic, and I've read 1 tutorial, 1 amazing book, skimmed a bunch of others, but mostly spent countless hours/days/months at a time pouring over various aspects of an OOP language for z80, and compiler techniques ... this is happening ... maybe not tomorrow, but it will happen

...instances and tokens... Yes. This is why I did not actually use the Java ENUM; but my Token class contained a whole list of static final instances for all the keywords and operators, and some "signals" used by the compiler; For identifiers ("names"), it would store an internal tree of Token objects for each identifier it found. When it encountered one, a method would feed it into the tree, and if it existed already, it would return THAT instance; otherwise it would make a new instance and put it in the tree, and return that. That way, comparing names, keywords, operators ... anything... was a matter of straight-up reference comparison ( == rather than .equals). For numbers and strings (and other literals) though, I just let it make new ones. Anyway, each token object contained a final int value that flagged what "kind" of token it was, another final int that stored bit-flags (or for number tokens, stored the numeric value), and a string value that contained the actual string-value of the token. That might sound like a lot of work, but each final instance is declared with the right values in the first place, and identifiers get certain values set ... and then there were methods that looked at that kind of information, so you could just get a token and ask "is it an operator? is it an overloadable operator ... with 1 or 2 arguments (or both)? is it a keyword? is it a control-flow construct? is it numeric?" ... etc, and those checks would not have to check if it was one of some 50 tokens, but just a simple value or a bit or something.

As for OOP on everything else, I had OOP constructs to represent classes, functions, variables, blocks of code, statements, expressions, etc., so pretty quick I could get a whole structure of a program into a very easy to manage tree-like structure, and easily go "Ok, let's look at all the classes and make sure they don't have any circular inheritance, and that they behave together". I had constructs for DataTypes too, which were flexible (polymorphic; some were just primitive Tokens; others were classes; others were complexities of arrays of things). One thing I may do differently this time though ... I went back and made everything that could be the "entity" referred to by an identifier to inherit from "Entity", so that expressions and variables and so on had direct references to "entities". Then I could go back through and replace all the references to Identifier tokens with the actual things they were referencing, without damaging the structure of the parse-tree ... that was actually a bit of a nightmare, because it had to be in a very careful order so that one could identify inner/inherited namespaces properly ("a.b.c"); and the way it handled "private" and "protected" stuff was a bit interesting (it used the "invisible" technique, so things were suddenly "undefined" rather than just restricted). ... But I've done more study about ways to use a symbol table, and I think it would be fine to just stick with that