This is coming along quite nicely. Do you have any ideas when you might release a beta? (stab me if you said anything about this in previous pages)

Clarification of changes:

 * Namespaces will be allowed to have type-parameters.
 * Constructors will be as just explained in previous posts.
 * "Virtual functions" are stored directly in their container as function-pointers.
 * Functions can be mapped to other functions without relisting arguments (we can discuss syntax: "func x = y" or "func x(args) = y").
 * Interface functions may have default bodies; Interfaces may also contain data members (stored "by value"), which may have default values. This might result in the "func" keyword being required in interfaces again though.
 * CONSIDERATION: I'd like to remove "anonymous members" from structs, and instead (1) Allow datatype names to be used as variable names, and (2) Have structs automatically "inherit" the properties (i.e. members and functions) of ALL their inner members (with any conflicts having to be resolved explicitly):

// OLD:
struct A { int x, y; }
struct B { A; int y; }
b := B(A(1,2),3);
// b.x == b.A.x == 1
// b.A.y == 2
// b.y == 3

// NEW:
struct B { A A; int y; }
// ...Everything else is the same

Wow, that's a lot of change

Nice to see you back on it, do you have any idea when we will be able to generate a simple executable written in Antelope ?

Also, do you think this could be used to write KnightOS programs ? That would be awesome !

I was wondering a few months ago what became of this. Great to hear it's still alive!

Great to hear this isn't dead. I'm still quite excited to see how programming in this language is gonna be

I regret to inform that this is dead; but mainly because I have something better.
I hope you'll be excited to see what programming (or computering at all) in a fully-dynamic system is like.

To save time, I'm going to paste what I've said elsewhere about the end of Antelope and the start of SomethingNew (2 posts).

---

(Pasted from elsewhere):

Sorry for abandoning this, especially after all that went into it. This is mainly because life happened. However, there is much learning/thought to reflect on; so here are some of my reflections:

1. Top features I've identified that I'd love to have in a language:
A  - First-order functions & lambda syntax (C# linq queries simplify even further!)
B - Functions that can yield values and resume from the same point (aka "coroutines", "generators", or C#'s "enumerators").  My "cofunctions" (not the same as the mathematical term) took this a step further by reifying the function-object ("functors" in other languages) allowing direct inspection/mofification of the entry-points and current "position", and also letting these function-objects to be emedded within other objects with full access to other members and vice versa.
C - Code that is interpreted / pre-compiled at compile time. I found this is BEST done in terms of all the built-in language features, rather than providing a separate syntax/language JUST for interpreted code. LISP does this by allowing macros that have the full power of the full language & other code. The D language does this very well by allowing meta-operations on the code using regular D code itself.
D.i - Use of "interfaces" to allow objects of ANY type to be used somewhere, so long as it has the correct members (Google's "Go" does this well). This provides the feel of dynamic "duck" typing, but with compile-time static type-checking.
D.ii - Ability to provide "default" members of interfaces.
E - "Traits" - that is, reusable blocks of code (object definitions) that can be combined statically, but WITHOUT introducing an inheritance relationship; it's just a clean mechanism for code-reuse. Traits are more refined than "Mixins", because you have full control over how to resolve conflicting names when combining multiple traits, and you can also map things differently (e.g. use a trait that provides behavior X and requires behavior Y, but provide "Z" in place of Y, or take X but call it "W"). Scala's "traits" are actually Mixins, because they do NOT allow any control over mappings, and they manipulate runtime inheritance hierarchies rather than combine code statically.
F - Reflection using "attributes" (as in C#; "annotations" in Java). This essentially treats the parts of a program like objects, allowing you to attach custom properties and behaviors to parts of the AST (e.g. to a "class"), without any impact on the RUNTIME entities that the relate to. In C#, this is done by creating runtime representations of everything (e.g. you can inspect classes and their members dynamically at runtime); but I was having this all be accessible at RUNTIME. That is code, code that can manipulate / be conditional on other code at compile-time. The D language does this very well. Languages that are self-hosting ("bootstrapped") like LISP or REBOL do not NEED reflection, because everything is already in the same "layer".
G - Default arguments for functions. My special technique for this is to insert the assignments of default values as extra instructions at the top of the function, and have multiple entry points in the function. To use all defaults, the function is entered at the "top"; when one default value is overridden, the function is entered "after" that default assignment. This not only saves code space, but allows the function to be referenced as EVERY sub-set of function type by referring to the correct entry point (e.g. F(A, B=X) is an F(A) and an F(A,B)). C# handles defaults by manually inserting the default values at all the call-sites, which means that the calling code can be "wrong" if the actual function-definition is separately recompiled with different defaults.
H - Function closures. I accomplished this through the "cofunction" implementation (B), though I had decided to remove them as an explicit language feature and instead have the compiler "detect" when to use them. That is, any function declared inside another function or class that references contextual data would automatically create a function-object to track it (or embed this data in the parent object, as applicable).
I - Generalization between functions and methods. Most languages do this by making methods a generalization of functions (e.g. the D language) by having the "this" argument count as the "first" argument (e.g. an O.F(A,B) is also an F(O,A,B)); but I did this by making functions a generalization of methods (e.g. an F(A,B) is also an <null>.F(A,B)) by reserving a special register (IX for z80) for passing the "this". This allows something that takes an F(A,B) to take an O.F(A,B) (JavaScript allows this by resolving "this" separately the function arguments). This also ties into J:
J - Generalizing all aspects of a source program into an object model. That is, a "class" and its static members are actually stored as an "object" which can be passed around or even inherit from other classes. Namespaces (including the default one) are also objects like this, and so all global/namespace-level declarations are members of some object (and thus all functions are "methods" -- but the passing of "this" is optimized out of the compiled code, because the allocation of these namespace "objects" is statically determined and thus so are it's members). This also allows one to define the namespace of a whole program (or part of one) to inherit from another class or compose traits into it, thus bringing OOP facilities to the level of the whole program.

...The above started as a 3 item list of 3 sentences. I forgot how much I put into this!...

2. I'm glad to see other languages/tools available, even though I didn't finish this one.
When I started, there was NOTHING like this, and mostly I really wanted to introduce a more general/full/open-ended language than the built in TI-BASIC (without assembler being the only other choice) so that others could experience the joy of programming on a fully-programmable device that is accessible to many. ... But since then, there is AXE, GRAMMER, and perhaps others, and that makes me happy and reduces my urgency. Big props to Xeda and Kevin for that!

3. ...I've had a bit of a perspective change on "language", which makes it hard to want to invest too much into one. I've been following past/present key figures such as Jim Coplien, Rich Hickey, Bret Victor, Alan Kay, Christopher Alexander, Richard P Gabriel, etc. (I actually found a GOLD MINE with lots of videos from many of these guys), and traced some of the roots of OOP and modern software paradigms to their origins to find that much of current view of what software & programming is, is a reduced form of a once grander picture. I've been one of many to try to find the next better language, paradigm, tools, etc. ... but this is just the software culture chasing its own tail. What needs to change is how software ITSELF is thought of, and the tools we use to do that cannot do that for us. My first wake-up call was recognizing this delimma as called out by Jim Coplien (and it took a year of study to for me to finally see what he's talking about), but does an excellent job of pointing this out (and demonstrating this could change), as does Rich Hickey (especially if you consider his statements of simple representation in a GENERAL sense, rather than just promoting functional programming or Clojure), and Alan Kay has a lot to say, but is very abstract. ... You cannot language or unit-test or TDD or tool your way into good software design; you have to think about software design itself, which means understanding HUMAN models of software. THAT should shape language & programming paradigm, but instead the software industry has let the opposite happen. ... places like THIS do a lot of good though in supporting open-ended exploration & learning; but there are nonetheless some DEEPLY ingrained views that come with being a programmer nowadays, and a lot of it is upside-down, but it's hard to change or even challenge.

... I see a world of software in which "language" becomes a malleable thing that can be adapted and mixed selectively or on the fly, rather than as a rigid distinction between one language or another. Ideally, you want to be able to create whatever software you want using whatever paradigms and language tools you want, without having to have had someone package it up into this static thing called a "language". Less like choosing between Legos or K'nex and more like being free to use any of all of paint, markers, crayons, pencils, charcoal, clippings, staples, glue, etc. etc. on your paper, and not even being limited to those things, or even to paper.

---

A lot of this was me trying to make the "perfect" general purpose language, and I was never satisfied with it 100%, so it never got done. Now that I have kids and a career, I see no priority for something this big; though I enjoy the discussion, and maybe someday I will use these ideas somehow. I've also had some changes of heart as to what to pursue in software, it's put me off of pursuing "language" too strongly. It's like Jim Cope says about language.

Anyway, I'm still all about the ideas, but I have nothing to offer beyond that at this time.

As for "the old one" (I assume you are talking about Antidisassemblage / SquirrelBox), yes that was a precursor. It was largely a first-time crash-course attempt at a language & compiler (which I'm still somewhat proud of); but over time I've learned that I could do SO much better! ... But I don't know if it will come to be in any time span that anyone is willing to wait for.

Anyway, I'll add further thoughts to my previous post (which I left "in progress")

Thanks for following my work though!

---

If anyone is interested in what I "moved on" to, here it is: https://github.com/d-cook/Objects

The idea is a software system that escapes the rigid boundaries of traditional languages and software tools, by empowering the end-user to create whatever things & behaviors they desire. It will act as a tool with a UI for creating and manipulating data & code in the form of objects, including all parts of the system itself (interpreter, UI, etc.). This will work the system will be made out of the same components that it edits, which can all be live-edited.

One idea for how this can be used is to replace traditional software development (code in language-X, depends on compiler- or IDE-Y, etc.), a software project can be its own self-contained tool that is its own editor, compiler, and UI for whatever software is being developed. All these pieces can be used on each other, and you can thus create the ideal everything (language, UI, etc.) for the thing being developed, and it's all just part of "the code". And it need not be uniform through-out (e.g. a chunk of code that contains its own interpreter or UI just for that part). That is one example, but the possibilities are endless.

...

Beyond that, as I am not the only one doing "this kind of stuff", I've actually formed a collaboration with others who are seeking to redefine software in similar ways. Check it out (it has its own brief explanation / history): https://github.com/d-cook/SomethingNew

_{Edit (Eeems): Merged triple post}

It's hard to explain the whole thing, but I can explain what I mean by escaping "language" (or at least escaping compiled language):

Instead of writing a program in language-A or language-B and being limited to using only the features of one language, you should instead be able to mix and match whatever language features you want, even ones that you create yourself. Or you should be able to modify those features just for your program. So how do you do this?

Instead of using (or writing) a compiler for some language, you write your own program to generate the program you want. This would be more doable if you take the code that normally would be in a compiler, and instead make it part of a library. A compiler creates structural representations (AST) of the code that it compiles, so instead the library would be a tool to build parts of that representation and give them back to you. You could then modify them, or create your own somehow; and then you hand them back and say "ok, build the program from these".

Think of uncompiled source code (written in a compiled-language) as a program that makes an executable program, and the compiler as the interpreter of that program. When viewed in this way, declarations within code (classes, functions, variables) act as imperative commands to create components of a program. Replacing these "commands" with an API & user-defined functions would allow programs to be generated with any components & mechanisms, rather than from a fixed set of "language features". No more language restrictions!

::instead of this:: class Foo { Bar b }
::you write this:: myClass = MakeClass("Foo"); myClass.AddMember("b", myBarClass)

::another example:: myTrait = new MyVeryOwnTraitsImplementation("ResizableThing"); myTrait.ApplyTo(myClass)

This is what makes languages like JavaScript so powerful: many things that are "declarations" in other languages are actually imperative calls to user-defined functions. This is why people have been able to make so many different kinds of object-models (etc.) in it. This makes things like compiler hooks and reflection mostly obsolete.

----

Now you might notice that the program that is generated by your program has whatever features and structure you want; but what about the program that did the generating; what language is that written in? Two possible answers are:
(1) It doesn't really matter, so long as you can generate whatever you want from it.
... However, since it just has to "run" once, it is more important for that code to have good expression than for it to be efficient, and that screams "interpreted language". Also, why would you want to have your source program, feed it into another program called a compiler, which generates an executable program, which you run to have it generate the program that you care about? Why not just run an interpreted program that generates the output program? So though it really does not matter what language the program-generating-program is written in, a compiled-language has no gain here, but the advantages of an interpreted language do apply.
(2) The only other option is to "close the loop" with some meta-circularness. That is, a software system or tool that is self-defining, self-modifying, etc., which is only possible if everyrthing (interpreter, code structure, etc.) is accessible at runtime. That is what my Objects project is about, except that it will do more than just that (e.g. a UI through which all things can be viewed or changed at runtime by the user, including the workings of the UI itself).