Re: [boost] Any interest for a parser class?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-22 09:23:49

HartmutKaiser_at_[hidden] wrote:

> ... The main misunderstanding between us is IMHO the term
> _parser_. I use this term in the strict analytical sense. It only
> analysis the structure of something and tells, if this structure was
> met. 

Yes, it seems that we have different idea of parser :-) E.g. presense of 
parameters looks to me just a syntactical matter. 

> I do not discuss the details of the library. All I want to say is, that
> the task of _parsing_ should be done with some existing tool to be
> flexible and extensible, and not craft it by hand, to end up with a
> dozen different hand crafted parsers in boost. And because I know Spirit
> quite well, and know how powerful it is, I propose to use Spirit for
> this _parsing_ task. No less and no more.

I would be hard to convince anybody by argument only. Let's take a breath. 
I'll try to complete command line parsing library using hand-crafted code 
that is already written. If anybody will be interested, he will be able to 
reimplement parsing using Spirit. Then, it could be decided if an option to 
use that implementation is desirable. 

> > > These steps you have to go regardless of the parsing methods you
> > > choose. The parsing (and system/library) method only helps you to
> > > granulate your cycle
> > >    syntax check -> semantic check --> syntax check
> >
> > Why do we need extra syntax check? Can you elaborate?
>
> Because the user may have gotten your particular option structure wrong.
> For instance in stead of
> -option=parameter he wrote -option-parameter or something like that. To
> catch those easily you shou have a formal understanding of your expected
> input structure == parsing == syntax check.

This is needed only if parameters presense, etc. is handled at semantic 
level, right?

> > In fact, hand crafted parser looks more attractive because
> > the grammar is
> > simple but there's a need to handle cases such as given at
> > the top of this message, and provide reasonable error
> > messages for all possible cases.
>
> It more difficult to maintain, it's more difficult top understand and
> flexibility is more difficult to achieve than when using some formalism
> to describe the expected option structure.

Again, we'll have to find out by experimentation.

> > > Regarding Spirit I must say, that some of such capabilities are
> > > already in place (for instance the possibility to decide, how many
> > > items the parser has to match on the base of a already matched
> > > itemcount:
> > >
> > >     int itemcount = 0
> > >     rule<> r = int_p[ref(itemcount)] >> item.repeat(0,itemcount);
> >
> > This is surely an interesting feature, but how is it related
> > to a command
> > line?
>
> My god, this was a sample, a concept, a whatever and has no, I repeat:
> no relation to command line parsing in the discussed field.

OK, sorry, the question is withdrawn. 

- Volodya