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}

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

I've decided to forego the idea of traits for Antelope. It's a great idea, but I found that most of the same expressiveness is already available from the fact that methods are declared separately, interfaces are applied automatically, and parametric types fill in the rest.

Some other changes I may make:
 * Namespaces may have type-parameters (namespace Foo<T>;) so as to build setups more generically (not only would you not have to do this to every method, but you could also have static/global T values).
 * Optional Constructors: This would change construction to use parenthesis, and optional constructors (and destructors?) would be declared within structs:
struct Foo {
   int x; int y;

   new(int xArg, int yArg = 5) { // Constructor
      x = xArg;
      y = yArg + x; // Now you can map values differently
   }

   delete { ... } // Destructor
}

f1 := Foo(1,2); // x=1, y=1+2
f2 := Foo(1); // x=1, y=1+(5)

struct Bar { int x,y,z; } // Constructors not required.
b := Bar(1,2,3);(Another option would be Kotlin's approach)

Some other ideas I'm toying with:
 * Changing lambda syntax from (args)=>code to { args => code } (and from =>code to { code }). I'd only do this so I could allow these to come AFTER function-calls when it is the last argument (Kotlin does some fancy stuff this way). Call(1,2,=>{code}) would become Call(1,2) { code }
 * Singleton objects (e.g. "object x { ... }" declares x like a struct, but that x is also the one and only instance of it)
 * "Class (struct) objects" as in Kotlin - a struct may contain a singleton object, which is referred to externally by the class name itself. This can be used to encapsulate "static members", but be referred to as a variable. This object can compose (inherit) from another struct for added functionality.
 * Change variable syntax so that types come after a colon (func f(x:int, y:int, z:int = 3) { ... }). This matches how return-values are given, and would make parsing types much easier (which is also true with constructors, since then Foo{1,2} becomes Foo(1,2) and can be parsed as a function-call). Also, this makes "A := B" more sensible for type-inference, since the type is "left out".

The only other thing I am debating is whether "virtual" functions should be stored directly within structs, or accumulate in an array as a "vtable" (C++) aka "class descriptor" (Java). I'm wanting to just keep them as pointers, because I want the language to be VERY oriented around using interfaces INSTEAD of using that kind of "inheritance". This allows embedded function-pointers to count as methods, and it is still POSSIBLE to construct a vtable (e.g. to mirror some hypothetically already compiled setup if necessary).

Thoughts?

NEW SYNTAX FOR OOP IDIOMS!

To test the feel of everything, I compared a simple OOP example from Java/C# with the "equivalent" Antelope code, and found it to be bulky and nasty. Therefor, I am wanting to rework some of the syntax relating specifically to "inheritance" idioms, as follows (with "..." indicating "no change"):
PSUEDO-JAVA/C#        | | ANTELOPE (new syntax) | | ANTELOPE (old syntax)   
========================================================================
class Fooer {         | | struct Fooer {        | | ...                     
  void Foo() {        <1>   func Foo() {        <1> func(this) Foo = func(this) {
    Print("Foo ");    | |     Print("Foo");     | |   ...                   
  }                   | |   }                   | | }                       
}                     | | }                     | | ...                     
                      | |                       | | ...                     
class FooID : Fooer { <2> struct FooID {        <2> ...                     
  int id;             | |   int id;             | | ...                     
                      | |                       | | ...                     
                      <3>   Fooer {             <3> Fooer = Fooer {         
  void Foo() {        <4>     func Foo() {      <4>   func(this) {         
    Print("Foo ");    | |       Print("Foo ");  | |     ...                 
    Print(id);        | |       Print(id);      | |     ...                 
  }                   | |     }                 | |   }                     
                      | |   }                   | | }                       
}                     | | }                     | | ...                     1) I'd previously given the "func(this..." syntax for declaring function-pointers "as methods" (i.e. "f.Foo(f)" shortens to "f.Foo()"), which allowed "virtual" (late-bound) methods to be "simulated". However, letting these be declared directly as "internal methods" looks much cleaner, matches the common OOP idiom/paradigm, and still gives control over where they are stored in the struct.

2) Antelope rejects traditional "inheritance" in favor of composition. Instead, anonymous members provide transparent access to their internals, as if they were "inherited" directly into the containing struct. Thus, the "inherited" Fooer appears in the body of the struct rather than at the top (as in 3).

3) Since anonymous members exist soley to "simulate inheritance", it is just redundant to have to repeat the anonymous type twice when a more compact form will do. This form is suggestive of embedding an "anonymous class" within a struct, which is exactly the intent (as in 6).

4) Since "inheritance" is simulated by composition, the new "Foo" function must be embedded directly in the anonymous Fooer. However, the only safe option is to use a "Fooer" method (since a "FooID" method could have misalignment issues) declared anonymously (to hide it from "Fooers" outside of FooID) and then type-cast to "FooID" within the method. This new form takes a non-method function definition for overriding (replacing) "inherited" methods, which then does these things automatically (using offsets if necessary). These can be given anywhere in the initialization list, and are skipped if omitted.
PSUEDO-JAVA/C#        | | ANTELOPE (new syntax) | | ANTELOPE (old syntax)
======================================================================
Fooer foo = Fooer();  <5> Fooer foo = Fooer{};  <5> ...                   
FooID fid = FooID(5); | | FooID fid = FooID{5}; | | ...                   
                      | |                       | | ...                   
Fooer moo = Fooer() { <6> Fooer moo = Fooer {   <6> ...                   
  void Foo() {        | |   func Foo() {        | | func(*Fooer f) {     
    super.Foo();      | |     Fooer.Foo(this);  | |   Fooer.Foo(f);       
    Print(" Moo!");   | |     Print(" Moo!");   | |   ...                 
  }                   | |   }                   | | }                     
}                     | | }                     | | ...                   5) Initialization values are given directly "{...}" rather than via a constructor "(...)". The first variable declaration can be simplified to either "Fooer foo = {5};" or  "foo := Fooer{5};" for conciseness.

6) "Inner" methods are normally skipped in initialization, but new versions can be defined for them (in any order) (as in 4). This very closely resembles an "abstract class" declaration in Java, which likewise creates an instance with "new" methods (only the Antelope version does not require a "new version" of the struct: this is merely a regular initialization which passes an anonymous function to the function-pointer "Foo").
PSUEDO-JAVA/C#               | | ANTELOPE (nothing new here)
=============================================================
void FooFooer(Foo f) {       <7> func FooFooer(*Foo f) {     
  f.Foo();                   | |   f.Foo();                 
}                            | | }                           
                             | |                             
FooFooer(foo); // "Foo"      <8> FooFooer(foo); // "Foo"     
FooFooer(fid); // "Foo 5"    | | FooFooer(fid); // "Foo 5"   
FooFooer(moo); // "Foo Moo!" | | FooFooer(moo); // "Foo Moo!"7) In Java/C#, pointers ("references") are automatic. In Antelope you have to use them specifically (and you should, because they are more efficient).

8) The compiler will automatically pass the address of these variables so as to match the type. Otherwise, this code is exactly the same. Alternatively, FooFooer could have been written as a method ("func Fooer.FooFooer()").

NOTE: Although there were short forms (e.g. "Foo :=" rather than "func(this) Foo =" (at 1), or "Foo := Fooer{}" or "Fooer Foo = {}" (at 5)), I used the fully expanded forms for a more complete comparison of the fully written out forms.

*Bump* - I have made changes to the Overview, with the following changes:

 - Tuples can now have empty items (e.g. use "(,x,)" instead of "(_,x,_)").
 - Added a detailed section just for namespaces.
 - Changed the preprocessor directives to be more traditional
 - Elaborated on how default values work (not the same as in other languages!)
 - Gave example of how anonymous entities in a namespaces take on the namespace name.

I have made all recently mentioned changes to the grammar!

 - Templated types (e.g. Foo<T:Printer> { ... } )
 - Extra "this" type for cofuncs.
 - No more embedding of funcs or cofuncs within structs or cofuncs (enforces clarity)
 - You can now be more liberal with the "dot" access (A.func(...), B.(*type), etc.).

Have a look

1) you could just make Printer an abstract class with a default method
2) Also, are you sure Foo and Foo<T> would have the same methods?
3) Foo<T>'s type would probably be something like IEnumerable<T>.

1) There are no classes in Antelope, and no "abstract" mechanism. There are just structs, interfaces, and methods, which are all separate features (to be very technical, nothing "has" methods, but there may "be" methods "for" something; they are given additionally). However, you can use embedded function-pointers to simulate some of that behavior:

struct abstract {
   int x, y;
   meth := func(this, int a, int b) { x=a; y=b; };
}

a1 = abstract{1, 2}; // uses defualt method
a2 = abstract{1, 2, someOtherMethod};
2) I am actually leaning toward the "templating" setup, so that if there is a "Foo<T>", then it will be incorrect to have a plain "Foo". The compiler will generate different methods for each type used, but will share methods which would be exactly the same. This means that you can use a pointer to keep everything generic:

struct Foo<T> { *T value; } // always the same size
func Foo<T>.Bar<T>() { ... } // always the same everything
func Foo<int>.Bar() { ... } // THIS one is specific to ints.

c := Foo<char>{'5'};
b := Foo<bool>{true};
i := Foo<int>{123};

c.Bar(); // inferred as c.Bar<char>, or Foo<T>.Bar<T> where T = char
b.Bar(); // inferred as b.Bar<bool>, or Foo<T>.Bar<T> where T = bool
i.Bar(); // inferred as i.Bar<int>, or the separate Foo<int>.Bar

// --- Another just to clarify: ---
func A<T>(T arg) { ... } // Different per type-size (and per differing operations on T)
func B<T>(*T arg) { ... } // Same per type, so long as nothing type-specific happens
3) ...Nothing would be quite like "IEnumerable<T>"; though yes, they share the same kind of generic idea. On a side note though, Antelope abandons the concept of "iterators" as they are in Java, C++. Instead, you'd iterate over things directly within a cofunc (which, by the way, was inspired by the "enumerators" or C# and the coroutines of Lua):

struct Tree<T> { T value; *Tree<T> left, right; }

cofunc Tree<T>.InOrder<T>():T {
   if(left != null)
      for(int i : new left.InOrder{}) { yield i; }
   yield value;
   if(right != null)
      for(int i : new right.InOrder{}) { yield i; }
}

Tree<int> tree; // Tree of int values
...
for(int i : tree.InOrder{}) { Print(i); }
EDIT: I actually found that using function-pointers as "visitors" is a MUCH more efficient pattern:

struct Tree<T> { T value; *Tree<T> left, right; }

func Tree<T>.InOrder<T>(func(T) process) {
   if(left != null) { left.InOrder(process); }
   process(value);
   if(right != null) { right.InOrder(process); }
}

Tree<int> tree;
...
tree.InOrder(Print);
// Or: tree.InOrder(i => somethingElse(i));(SEE MY NEXT POST)