Re: [ANN] Spirit C++ parser framework.

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-05-24 06:31:59

Joel de Guzman wrote:

>> 1. Potential scope
>>     Joel, could you make some more grammars and give performance results
>> compared with traditional parsers, time needed to write and debug parsers,
>> and so on?
>>    (Besides, your code fails to compile under g++ 3.0 and bcc 5.5.1).

>My first priority is to compile Spirit with g++ and bcc. 
I've done it. You just have to check if my changes are ok from semantical 
point.

>As for more grammars and performance analysis, that would involve
>more time. But certainly that's something I intend to do.

>>It is therefore necessary to establish which grammars are suitable. 
>>This can be done through experiment only.

Greg Colvin wrote:
>And by understanding, theoretically, just what kind of parser
>Spirit is, and what the known performance characteristics of
>that kind of parser are.

>That said, ease of use is much more important than performance
>for the kind of things I imagine Spirit being used for.

Joel de Guzman wrote:
>Scope? Well admittedly, the original intent of Spirit is for small to
>medium sized grammars. Internet protocols, files, html, xml, scripting
>languages, possibly basic variants, pascal variants, pre-processors,
>resource description, lexers, and yes I intend to use Spirit as an engine
>for another parser.

Theoretical study is not likely do give us much. Backtraing parser have 
exponetial complexity in worst case, and  "high priests" would find their use 
impossible. 

The reason 

> BTW, could you give me a parser that does not choke on C++?
Well, EDG folks somehow managed to parse the language :-).

>> 2.  Syntax
>> Proposed syntax has prefix "*" and "+". This is likely to confuse anyone 
who
>> knows what EBNF is.  Reuben Fries and later David Abrahams have already
>> proposed different syntax. Is it better? I tend to say "yes".

>I disagree. 
Well, our opinions differ. So, we need, as Greg Colvin put it, "argument
and experimentation towards finding a nice, clean syntax.". I don't believe 
any argument can be usefull there -- too much is based upon personal 
preferences, so  

The iterator syntax, apart from being more verbose (and clutters
the grammar), requires more time to comprehend. I'd say go for both. I tend
to agree on the infix + instead of >> for sequencing though.

>> 3. Possible extensions
>> Douglas Gregor's idea of compiling Sprint expression looks very neat. I
think
>> that if some automata building libary is available, it can be easily
>> accomplished. However, such a library should be completely independent
one.
>>

>Agreed. this is a really cool avenue to explore.

Well, see my parallel post exactly on this subject.

-- 
Regards,
Vladimir