Sorry to link it like this rather than posting all the details, but I already have it nicely formatted:

[EDIT: here is the current link): http://tinyurl.com/z80antelope

This language has gone through MUCH theorizing and many changes, and now it is about ready to code. Before I do so, I'd like some feedback. I have many of the same goals as were with the AXE Parser; but the differences are large enough that the two language will not be in direct competition with each other. For example, OPIA must be compiled on a computer; but it has the same feel and features as C#/Java/C++, and rather than having "everything you need" built in, it can be used or developed in all different kinds of ways.

Shouldn't this go in "Other calc related ideas and projects"?

Also, sounds like a cool idea . I've been secretly working on something similar for a while so, so feel free to ping me if you want to discuss some aspects of the language and some down-and-dirty specs of the 84+

So, in a sense it's a C# or C++-like language that compiles into Z80? (If so, then you are a god!)

It seems that it is a very C++ like language(I read through part of the readme)
You are an epic god shkaboinka

This reminds me of something Ashbad and I tried to do a while ago. But it never really got started. I think I still have the basic compiler source that I started on (C++). Want it?

perfect.
What language were you going to do the compiler in? C++?

Humm. Java-based assembler. I don't happen to have one on hand, but I would love to work on one. I would also love to work on this compiler thing.

I love compiler-theory. It's so interesting. I prefer making class instances for each statement, but I think your way might be better, I'm just a little worried that it wouldn't have support for class names and such (you really need instances for that). But I think a middle-ground could be achieved.

EDIT: Btw, what IDE do you use?

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