Anyone interested in a Spirit for D?

[Bill Baxter]

Walter Bright wrote:
> Bill Baxter wrote:
>> But given Don's experiments with compile-time text parsing in D, it's 
>> conceivable that in D the above parser could just be created with:
>>
>>    r = make_parser("real_number (',' real_number)*");
>>
>> I.e. use the EBNF version directly in a string literal that gets 
>> parsed at compile time.
>> That would be pretty cool.
> 
> Yes, it would be. But there's a catastrophic problem with it. Spirit 
> enables code snippets to be attached to terminals by overloading the [] 
> operator. If the EBNF was all in a string literal, this would be 
> impossible.

But maybe you could allow the user to access those terminals via strings:
    r.lookup_terminal("real_number").add_action(&func);
or just
    r.add_action("real_number", &func);


>> So I guess the real benefit of a compile-time parser-generator is that 
>> your grammar can be _verified_ at compile-time.
> 
> I disagree. I think the real benefit is avoiding reliance on an add-on 
> tool. Such tools are a nuisance; making archival, maintenance, etc., 
> clumsy.

Hmm.  Well if no external tools is the main benefit, then simply making 
Lex/Yacc (or more apropriately, Enki) into a library should be 
sufficient.  I guess you do need some way to attach code to terminals at 
runtime, but that's doable via various existing callback mechanisms. 
The machinery needed is basically the same as signals/slots.  You just 
need to be able to do something like
         connect(ASTreeNode.accept(), mycode);
  at runtime.

Then you should be able to get this kind of thing to work:

    auto r = make_parser_node("real_number (',' real_number)*");
    r.add_action("real_number", &func);

using nothing but runtime parsing of the grammar to build your AST.  No 
fancy templates needed, except perhaps in adding the callback to &func.

That kind of thing could be done in C++ too.

--bb