[lmi] Re: Parsing, and parsimony

[Vadim Zeitlin]

On Tue, 06 Sep 2005 14:15:30 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2005-9-6 13:47 UTC, Greg Chicares wrote:
GC> > 
GC> >    using boost::spirit as a parser (so we'd have RPN) and boost::phoenix
GC> >    instead of boost::lambda (because the same author wrote spirit and
GC> >    phoenix).
GC> 
GC> In 'input_sequence.?pp' we have a hand-coded recursive-descent parser.
GC> It's a lot like Stroustrup's example in TC++PL3, which in turn is a lot
GC> like the example in the Red Dragon Book. It's 1526 lines of code to
GC> maintain, or 3222 if you count '*seq*.?pp'.
...
GC> If it's a good idea to use spirit here,

 I've read the code now and, globally, I think it is. There are a few
caveats though:

1. I've never used spirit before so I could miss some unforeseen problems
2. I'm not sure about the error detection, i.e. whether it's possible to
   give as detailed error messages as needed in this framework, but AFAICS
   it should be
3. Spirit syntax is similar to BNF but not quite, e.g. let me rewrite your
   some productions of your grammar in it to show it (there could be errors
   in what I write but it should be sufficiently close to the real code to
   illustrate what I mean):

GC>   // GRAMMAR interval-begin: one of [ (

        interval_begin = ch_p('[') | ch_p('(');

GC>   // GRAMMAR duration-scalar: @ integer

        duration_scalar = '@' >> int_p;

GC>   // GRAMMAR sequence: span ; span

        sequence = span >> *(';' >> span);


   So if you want to really use BNF, you'd better switch to another parser
   (yacc, antlr, whatever...) and not Spirit.



 OTOH:

1. Spirit does look cute
2. It has excellent documentation, it's the best doc for any boost library
   I've seen so far
3. Integration with C++ code is very, of course, so it's much more elegant
   than yacc
4. This grammar could be implemented trivially in Spirit AFAICS


 To conclude, I think that if there are good unit tests for this code (I
did see input_seq_test.cpp but it has a few TODOs so I don't know how
complete is it), then it should be possible to complete the transition to
Spirit quite easily and quickly. I.e. writing the code with Spirit should
be very quick, it's just testing an ensuring that it works the same as the
old one which would take time and here the existing tests are crucial. But
if the tests can be trusted, this shouldn't take more than a couple of
days.


GC> then it may be a good idea to use spirit and phoenix elsewhere, as
GC> described above: we'd depend on fewer libraries.

 However I don't agree at all with this. AFAIK boost::lambda is much more
popular than phoenix. And I don't see any important (for us) advantages of
the latter compared to the former. And as you always have both libraries
anyhow (both libraries are header only, there is nothing to compile; and
there is no separate boost::lambda distribution, you always have to install
the entire boost) I don't see why shouldn't we use the best tool for the
job. IMHO Spirit should be very good for the parsing code but it doesn't
mean at all that boost::lambda can't be used elsewhere.

 Regards,
VZ