BLADE 0.2Alpha: Vector operations with mixins, expression templates, and asm

[Pragma]

Don Clugston wrote:
> The problem I was referring to, is: how to store both values, and 
> functions/operators, inside the tree. It seems to get messy very quickly.

It can, especially with the additional code you need to treat all those templates as specialized data types.

> I meant for this application. There's no doubt they're indispensable in 
> other contexts.

Oh, my bad.  Yea, it would probably be overkill for BLADE. :)

 >> Basically what you see here
>> is a chunk of the as-of-yet-experimental compile-time Enki parser.  
>> This piece parses the Zero-or-more expression part of the EBNF variant 
>> that Enki supports.
>>
>> The templates evaluate to CTFE's that in turn make up the parser when 
>> it's executed.  So there's several layers of compile-time evaluation 
>> going on here.  Also, what's not obvious is that "char[] tokens" is 
>> actually an *array of strings* that is stored in a single char[] 
>> array; each string's length data is encoded as a size_t mapped onto 
>> the appropriate number of chars.  The Bind!() expressions also map 
>> parsed out data to a key/value set which is stored in a similar 
>> fashion (char[] bindings).
> 
> Seriously cool! Seems like you're generating a tree of nested mixins?

Almost.  The generate.ZeroOrMore returns an arbitrary string, that may be another "map" or a chunk of runtime code; the 
value is placed in the "value" string that's passed in.  The *rootmost* generator is what compiles all this stuff into 
an actual chunk of mixin-able code.  It's analogous to how the current rendition of Enki works.

It seems overkill, but it's needed so I can do some basic semantic analysis, and do things like declare binding vars. 
I'm still looking for ways to simplify the process.

> Anyway, I suspect this will really benefit from any compiler 
> improvements, eg CTFE support for AAs or nested functions. And obviously 
> AST macros.

Definitely for AA's but not so much for AST macros - I get the impression that AST manipulation will only be useful for 
D code, and not for completely arbitrary grammars like EBNF.  Getting compile-time AA support would cut Enki's code size 
down by almost a third:

const char[] hackedArray = "\x00\x00\x00\x05hello\x00\x00\x00\x05cruel\x00\x00\x00\x05world";

Under the hood, this is what most of my data looks like.  Dropping the support routines for manipulating such structures 
would help make things a lot less cumbersome. :(

> I really think the new mixins + CTFE was a breakthrough. Publish some of 
> this stuff, and I think we'll see an exodus of many Boost developers 
> into D.

Agreed.  CTFE frees us from many limitations imposed by templates, and the added flexibility of mixin() pretty much 
gives us the same strength of javascript's eval() statement at compile-time.  It's a huge deal.

It's possible that we might find a handful of interested devs in their camp, but I think we're still back to the same 
old problem as with the rest of C++: momentum.  I sincerely doubt we'll see a mass exodus from one camp to this one 
regardless of how good a job is done here.  Of course, I'll be happy to be wrong about that. :)
-- 
- EricAnderton at yahoo