CURRENT ROADMAP:

I've cleaned up the Grammar some: I had to separate preprocessor directives from the rest of the grammar (this allows #if to be intermixed anywhere), made explanations MUCH shorter, and compacted the conventions into a small table.

I need to clean up the syntax classes section a bit, and then the example walkthrough at the bottom (which is WAY out of date).

After that, I will clean up the Overview by making it current, and I will try to cut down the explanations significantly, and try to provide more relevant examples.

So first a bit of maintenance, and then the coding. I hope to get that started before the new year.

My current thoughts on coding:

* I will get rid of Meta tokens used for indicating errors, line-numbers, and files. Instead I will have different phases of the compilation pipeline take something to receive error messages and file info, etc. so that it never dirties up any tokenized code.
* I will have still have the Token class just return a generic "end of line" or "end of input" token as they come, but as signals rather than as marks to be "kept" within the token stream.
* Preprocessing will act as a filter between the Tokenization and Syntax-Parsing layers: It will use the Tokenizer to get tokens for preprocessor directives as needed, but skip tokenization altogether when it needs to skip over code looking for an #endif or an #else (but still necessarily allow strings and comments to be tokenized out). It will keep track of line numbers and file info (either explicitly or via some interface to be passed in), and otherwise just spit tokens out directly from the Tokenizer to the Parser.
* The parser will act as if it is only ever working with one file. However, to avoid allowing multiple namespace and "using" instructions amid a file (those can only go at the top, and only once), The preprocessor will initiate a separate Parsing context for each file. From an API standpoint, the Parser can be invoked on multiple files, and the results can be combined.

I don't think that part will take very long; I see it as a precursor to churning out the syntax-parsing code which will spit out a syntax tree. Hopefully that will go fast too, since everything is all spelled out in the grammar. At that point, I'll have something that can "do stuff" with code, and even be interfaced with at an API level.

Nice changes, shkaboinka. I was actually looking at the old Antelope code a few days ago, and yes, I would agree that removing the Meta tokens is a good idea. I don't exactly understand the rest of your current thoughts you listed there (sorry...) but it's great that you want to start working! I'm really looking forward to when this'll start working!

Update: I've cleaned up the Syntax Tree Classes (the change is significant), so now it won't take too much to code a parser for them, along with some public API for them.

I will revise the walkthrough to use the updated rules and classes, and update the Overview to make sure that everything is current (and trimmed down, clean, and with better examples). Then I'll clean up the existing code some to make sure everything still fits nicely. Then I will give you a parser and tree API. I just want everything to be on a clean page first so that everything stays consistent.

FYI, I have been working very hard (mentally and "on paper") to make sure that everything fits together cleanly as I've revised things: The current syntax classes should be agreeable for data-flow analysis (tracing values and optimizing/precomputing code); My current vision for what comes out of the preprocessor is agreeable with code being parsed on it's own; ...etc...

Update: I'VE UPDATED THE WALKTHROUGH! Now I just need to bring the overview up to date, and I will have a solid foundation to fall back on if anything gets "muddy".

Any suggestions for improving The Overview (e.g. I intend to make the examples more realistic / concrete and remove a lot of "fluff")?

I think that the one biggest thing that you should do to improve the Overview is to split it into the Language Specification and the Implementation Details. For instance, the information about variable declarations, datatypes, and functions would all be in the specification, and the implementation details, such as the "self-falsifying conditional block" for static initializations as well as the Java compiler walkthrough, should be in their own article, because a different author might choose to implement Antelope differently.

Also, I think it would also be cool if you added another article that contains an entire sample program (or two) that makes use of every single element of the Antelope language, along with its expected output and a log from the compiler.

I'M JUST GOING TO JUMP INTO CODING and leave the Overview alone for now. The grammar is a pretty clear specification as it is, and the current overview catches 98% of anything else (albeit kinda messy). I do want to eventually redo the Overview, but I'll just think of it as fluff to add to a working compiler.


I just want the overview to be an overview; it doesn't have to hit every last point. The grammar can be the detailed specification. Any points that the grammar does not hit can be inserted into the Overview somewhere.


I don't really see that happening; especially since the compiler will be very interface-able with whatever IDE (or tool) you want to make. I'm thinking similar to how any Java-Language environment uses the javac compiler underneath.


I've thought about putting up an example at the start of the overview that uses many of the main features, as something to look at and quickly get a feel for Antelope.

I think I speak for all of us when I say "hurray!". Can't wait to see how this works out.

Hurray indeed! I very much look forward to this!

And once there's a working compiler, I'm sure there're some people here who would be willing to write some example code

PROGRESS:

1) I have the repository all setup! You can check-out a read-only copy of all the source from http://antelope.googlecode.com/svn/src (see the source page for more info). (This also helps me work between computers, which plays a significant role in being able to do anything more quickly).

2) I've made significant modifications to some of the code (mostly laying the ground for modularity, e.g. decoupling error-handling from everything else). Pretty soon I will have the preprocessor where it should be, and the syntax tree classes will follow.

Nice changes! Out of curiosity, what IDE are you using to write the code? Eclipse is my weapon of choice for Java, but I don't see any evidence of a project file.

I'm keeping that out of it! I just checkout the src folder directly into whatever project folder I want. One one computer I am using JCreator; but lately it's been flagged as malware??? ... So I'm using something called Dr Java on my new PC. It's not the most polished IDE, but I wanted something very lightweight.

In the past, I've just used notepad, and then ran javac on it manually (or using a custom batch file); and I make JARs by throwing them into a zip file, typing a simple manifest, and then changing the file extension. ... It's simple enough that I felt I didn't need to clutter my repository with anything IDE-specific.

Update: I have something you can see and test!

It's not much just yet, as I said I needed to revise things; but those things are almost all done! The preprocessor handles all but #if directives (which should be done very shortly), and the command-line interface now accepts all the arguments/options it needs (I might add more eventually though), and gives you instructions if they are missing or invalid.

I have yet to test it thoroughly, but I'll be doing that (and it certainly would be ok for anyone to do the same). As I said before, you can just check it out with subversion or tortoise SVN.

A demo of Antelope polymorphism (very much like Traits (with state!))

Code:

Notes:
* Since "@" does not create additional storage, you can map external funcs within their struct (e.g. "Imp{ func f @ Bar.f; }" instead).
* Constructors are called directly on the variable (initially or within other constructors), hence "this(...)" for Bar's per-item constructor.
* Constructors can be member-accessed if their arg-types are included, e.g. "Bar.new(*Imp)" to refer to the Bar(Imp) constructor.

I can see how that works. How does this change the old polymorphism model?

It was just a demo, partly to show that it's as usable / flexible / expressive as traits or other inheritance models (ergo, no need to add them). There are some minor grammar changes (while coding!) here and there, but the model is staying the same. <<VIEW THE CHANGE LOG HERE>> for a complete list of changes as they occur. I'm otherwise trying not to post updates without significant changes or until something big is "complete" (or to let people know that progress is happening after a long silence).

ON TO THE YET-UNCODED PORTION (I've finished revising/updating existing code)!
I'll be coding the Syntax Tree next, which builds a structure from the source code that can be analyzed (verified), optimized/interpreted, and then converted to asm code. (They can also be constructed directly via a public API).

I'd appreciate it if anybody is willing to give a quick test run for the now finished Preprocessor/Tokenizer: Download The Source Code (Java) and build it and run it, and give it some code to test. It gives instructions if you don't know how to specify files & options. (Use The Grammar as an aid in understanding the preprocessor directives you can use).

(If you are really clever, you can code up your own implementations for the TokenSource and/or ErrorHandler interfaces and plug them directly into the compiler, and watch as it magically works with something new to parse source code (e.g. a command-line input or a GUI with buttons) or handle errors (a popup?) ... This will be a lot cooler when you can do this kind of thing with the Syntax Tree classes and other aspects of the compiler as well).

OTHER BIG UPDATES:

* Finished incorporating overloaded operators to the language.
* Interfaces can require constructors and overloaded-operators.
* In addition to being constrained to specific interfaces, Type-parameters (for "generic" / "templated" functions, structs, etc.) can also be constrained to specific functions, operators, and constructors.
* Constructors/Destructors can now be internal or external (see previous code example).


Code:

Update: I'VE FINISHED CODING THE SYNTAX TREE CLASSES (There are roughly 40 of them)!

These provide the building blocks for constructing an abstract representation of an entire program (or set of programs). I still have to write the parsing for it (i.e. take results from the Preprocessor and instantiate the syntax tree from it), but it can currently be used as an API to "build a program" using OOP (instead of actually source code).

What's Complete:

* Language Design (The Grammar Rules, etc.)
* Tokenization (parsing source code into Tokens)
* Preprocessing (reading code from files and handling #directives)
* Interfaces for (custom) token-sources and error-handling
* Syntax Tree Classes (subject to slight modifications with time)

What to code next:

* Syntax-Parsing (instantiate a syntax tree from preprocessed code)
* Verify (make sure code is semantically correct)
* Optimize (Pre-Compute whatever possible)
* Generate assembly code from optimized code
* Optimize the assembly code

After that, I can publish everything and start writing libraries, integrating with shells/apps/etc., and perhaps make some fancy tools for Antelope (which will be very easy for anyone to do because of my use of interface-based compiler pipeline!)

Good work! Have you generated any sample programs in the programmatic fashion you describe to test it all out?

Not yet, though the couple of test files I have in there just do random things to test all the different aspects of it (e.g. all the correct and incorrect ways the code can be); but none of it is meaningful code yet.

By the way, I have begun coding the syntax tree parsing already (see the changelog or source for more specific info).

I have put so much time and effort and energy into this project, which I have long anticipated being my one big mark that I'd leave and offer to the community (and it would be very fulfilling to have designed an amazing language at all).

Unfortunatly I can no longer afford for it to be any kind of priority (SO sorry about this).

I have two options:

1) Archive the project away and maybe someday I can come back to it. The upside is that I'd be the one to see it through the right way. The downside is that it may never get done, and I'd be choosing to be okay with that.

2) Leave this project to someone(s) else. The upside is that I'd still have made something of it, and that others could make it happen.

(If nothing else, this was a great learning experience, and I hope it has/still can be that for others).

I will have to discuss this later, but please discuss if you can.

I'm truly sorry for doing this after all this time, but this is for the best. Thanks