The new layout seems a lot like (or at least the goals seem fairly similar to) Tangent.

Quote:
Moreover, this allows the programmer himself to define his own entities and syntactic extensions to the language.

Do you perhaps have a concrete example of how this looks/how it would work?

Not yet, unfortunately; I need to finish getting things like error recovery in the parser back up to speed before I can work on some of the initial extensions.

Conditionals and loops will be implemented this way, for instance; you'll end up doing something like this in the standard library:

void FlowControlLibrary::RegisterLibraryEntities(EntityInvocationTable& table, StringPoolManager& stringpool)
{
   table.insert(std:make_pair(stringpool.Pool(L"if"), FlowControlLibrary::Conditional));
}

void FlowControlLibrary::RegisterLibraryEntities(EntitySignatureSet& signatureset, StringPoolManager& stringpool)
{
   {
      EntitySignature signature;
      signature.AddParameter(L"condition", VM::EpochType_Boolean);
      signatureset.insert(std::make_pair(stringpool.Pool(L"if"), signature));
   } 
}

void FlowControlLibrary::Conditional(StringHandle entityname, VM::ExecutionContext& context)
{
   Boolean value = context.State.Stack.PopValue<Boolean>();
   if(value)
      context.InvokeEntityCode(blah);
}

Well, I obviously haven't thought it through entirely yet, as that last blah can attest [grin] However, that's the basic idea. That'll set up the bulk of the internals for handling the if entity, which will be invoked just like any other (non-function) entity:

if(foo == bar)
{
   debugwritestring("Equality!")
}

There's a couple little details to get sorted out, such as how to distinguish between entities that have inline attached code versus entities which do not (functions, really), but that'll be pretty easy once I get the rest of the prerequisite junk cleared up.

Okay. That (at least at first glance) seems to be... not something for the common end user. Just curious about the approach. Always good to read about other work in the area.

Yeah, it's definitely more of a systems programmer/library programmer type feature, rather than something that your day-to-day apps guys will need to mess with.

I made that decision for a couple of reasons. First, while I like the idea of highly mutable syntax in theory, it serves as a communication impedance in practicality. I'd like people to be able to say they "know Epoch" in the same way that one "knows C++ and the standard library" for instance. If the syntax is too mushy then this gives way to far too much mucking about trying to determine what code means.

This ties directly into the second reason I wanted to make it a little less accessible: abuse. Operator overloading in C++ is a great example of a controversial feature that is occasionally invaluable and often open to hideous abuses. By raising the barrier to entry just slightly, I can avoid a lot of that problem: the kinds of people willing to dig into extending the standard Epoch library aren't likely to screw up something as simple as syntax extensions. By contrast, people who are likely to do something evil (by accident at least) aren't going to have immediate access to the syntax mutation facilities. This makes it a bit harder to blow one's feet off.

I suppose. Though also with C++, template metaprogramming has a high barrier to entry, but that mostly just keeps people from learning/using it (not necessarily a bad thing in this case, but...).

Still, that's one of the things I do like about what I've settled on for Tangent's syntax manipulation: You get most of the benefits without being able to modify the syntax. The actual parsing rules are fixed. The actual rules for how tokens are processed into coherent expressions are fixed. Allowing the programmer to intuitively define/overload the types of almost every token provides a lot of the same 'fix the syntax to better match the problem domain' benefits without a lot of the gory details. And aiming the language towards a more literate path should (hopefully) make it so that programmers don't need to look too deep to grok what's going on in custom libraries/extensions.