It was intended with humor, of course, but really creating a natural language syntax is a tiny capability of Avail. We're working on the details at the moment, but we're fairly certain that every programming language ever written can become a mere dialect of Avail. Except running on the same jitted VM. And trivially able to intermix with code in other languages, even in the same module. Even within a statement. The RPN calculator example might give you an idea of what we can do today. Also, "Quiz DSL.avail" might be of interest, since it's not just traditional programming languages that Avail is going to eat for breakfast. Brace yourself for what's coming.
I'm still a little unclear on what language extension looks like when you want to do things other than adding new procedures. Do you have any examples of manipulating evaluation order (like choosing to evaluate arguments right to left or left to right, or handling certain arguments lazily) or adding new binding forms or a custom type system?
At this exact moment, Avail can only evaluate expressions left-to-right, except of course for functions (block expressions, using [] notation resembling Smalltalk).
However, I'm close to completing the macro mechanism that will allow the same flexibility of syntax present in method names (keywords/operator tokens, argument positions, guillemet-enclosed repeated argument groups, etc), but for constructs that run at compile time with parse trees instead of values. The actual macro mechanisms have been working for some time, but were disabled until we were able to represent the ~dozen syntactic constructs of Avail purely as macros. Then any new syntax wouldn't be in conflict with existing syntax. When that's working we'll toss the existing compiler (the one that knows anything about Avail's current syntax, like statements and functions and variable declarations), and use the compiler that knows nothing about Avail – just how to parse methods and macros. Then we'll be able to support arbitrary evaluation orders, declaration syntax, treating some expressions as lazy, alternative scoping models, etc.
As for custom types, we're investigating ideas about carrying purity annotations through user-defined control structures. Kind of hard to describe in this forum, though.
