Lexer and parser generators using CTFE

[Andrei Alexandrescu]

On 2/28/12 1:52 PM, Dmitry Olshansky wrote:
> To be truly successful it should have some distinct properties like:
> - being faster or identical to handwritten stuff we already have (like
> e.g. std.json ), reminds us of recent INI parser proposal, should be an
> easy pick for general parser.

Yes.

> - be flexible, the result need not be a predefined AST tree nodes,
> Hisayuki Mima's parser shows some nice movement in this direction

Yes. But AST creation should be supported without any custom code.

> - have reasonable compile times and memory consumption (though it will
> only improve over time)

Yes. I guess PEGs have problems there.

> Recalling EBNF parser idea that I run with before finally being dragged
> down by real life. Roughly I thought to follow hybrid LL(*) aproach,
> while I had a solid plan on doing DFA for lexer and parser lookahead,
> the other things were more or less floating.

Well, maybe you could integrate that within your up-and-coming research. 
Grammars have been considered a solved problem every five years since 
1970, and there's always new work coming :o).

> There is prototype of interactive regex matcher that
> works directly on stream (buried in std.regex), it even passed dry-run
> unittests back then. Though I had to postpone till I/O is sorted out. I
> really loved Steven's design with it's easy access to buffer and well
> thought out primitives, hope it will come about sometime soon.

An interactive regex would be a dream come true to me...


Andrei