Sorry DJ ... I began posting about it in both places, and got a decent initial response in both. However, it only REALLY took off at Cemetech, and thus decided to keep most of the posts there (they are time consuming, because they are thought out). Rather than just abandon [these people] altogether, I left notifications ... but I see how that could be a problem. I don't want to "steal" followers from one site to another, and I suppose I could have just copied posts and reposted them here. So much information was interchanged at Cemetech that I found it would be an overwhelming task to keep it all in both places; however, to give SOMETHING of substance, perhaps I will go back and take the key points and put them in a post here. That way there is a glimpse of what's going on, and some of the key discussion.

However, my project is hosted at google code ( http://code.google.com/p/opia/ ), and even when I discuss it anywhere, I leave links there regularly, because that is where one must go to see the language documentation and source etc. (I am not going to host it in multiple places). I will, however, go back and put a lot of the key discussion here as well.

Sorry for the misunderstanding! ... I promise a lot of information HERE soon.

ATTENTION ALL!

If you want to be involved directly and/or see what's what at this point, take a look: http://tinyurl.com/z80opia
I am hosting the project at Google Code, since it comes with a Wiki and repository!!!

... I imagine I've made many-ish changes since I've sneezed a word about it in here; but it is ready to start becoming code if there are no further points in the way (and if there are points, I have thought pretty hard about all the reasons for things, and its all very solid now).

Yes, thank you.  I've found many compiler books, and most of them were way outdated and all about the importance of using tools like "Lex" etc. ... Anyway, I've only ever really found 2 books very useful for me, and that was one of them. I at least glanced at every page, skimming over the stuff that was repetitive, ignoring what I wasn't into (i.e. JIT and Parallel stuff ... that's not happening on z80); but I totally soaked up some good stuff from it that I wasn't finding elsewhere!

The other book, which I think is the best book in the world for what it's about, is "Modern Compiler Implementation In Java" by Appel. That book showed all the good stuff about polymorphic language design, data-flow analysis, register-coloring, etc. Honestly, I don't quite remember what came out of the Dragon Book for me, just that it was helpful and I wouldn't have found it elsewhere.

There have been ideas I've come across on my own as well though, only to discover that it's been talked about in not a few places (Code mutation to store variables; using jump tables; and symbol tables ... I never understood them the way the books tended to explain them, but I came up with a "great idea" about how to track that kind of stuff, and realized that it was the same thing; only I'd do it in a more OOP manner).

...But yes, references are VERY important. When I first started on compiler design, I thought I could just "figure it out"; but I was referred to the "Lets make a compiler" tutorials by Jack Crenshaw, from which I mastered the idea of a recursive decent pattern and recursive expression parsing and tokenizing (which actually are quite fundamental if you want to make a compiler, period). ...anyway, from there is was my own tinkering and thinking, and then the Dragon Book, and then the Java book, and then a bunch of outdated books that I didn't get squat from ... But those 2 books (and Jack Crenshaw, which I think is an excellent place to start) helped more than anything else could have.

 ---> If anyone wants to be involved more directly, I just made a FaceBook group. Just search "OPIA" <---

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

I am going to do it in Java (packaged into an executable Jar) for 2 reasons:
 - It can be run on any machine.
 - It will code it as an API that can be exploited to construct a program in an OOP way rather than by typing it out ... if, hypothetically, someone makes such a thing; but it will be possible (like Bluej) ... basically, if another java-based tool wants to analyze OPIA code before compiling it, instead it can just have the compiler do it anyway, tinker with it, and then hand it back to the compiler.

I am going to make it command-line based, like the Java compiler is, so you just go "OPIA myprogram" or something; but you can pass in other things about where to look for files, and what environment to use (otherwise having to be specified in the code), etc. That will ALSO allow it to be interfaced with a nice GUI editor, which perhaps has it's own ideas about "projects" and managing files, and associating an environment in some other way than as part of the code ... I wanted it to be flexible. I can see this hooking right up to Notepad++, for example.

One other point: If there is a nice Java-based assembly compiler out there, that would be nice. Otherwise, I wouldn't mind undertaking to make one, JUST so that I can have one tool (or a couple of them) to spit out a ready program

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.