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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-21 10:22:48

HartmutKaiser_at_[hidden] wrote:
> > And how do I specify that "-xy" should be treated as two
> > options when 'x'
> > takes no parameter and as an option with parameter
> > otherwise? How will I
> > detect the case when there short option "f" and there's
> > long option "foo", in
> > which case "-f" can mean either the short option or the
> > abbreviated long one?
>
> That wasn't your initial question.

Sorry, but it was. Maybe, I haven't formulated it clearly enough.

> I think, that a parser will (and should) not be used for _semantic_
> analysis of the input stream.
> A parser
> - can check the correctness of a given input stream against a given
> _syntax_ rule
> - can invoke some semantic action(s) on different places during the
> parsing process if a part (or the whole) input grammar was matched
> successful.

Why do you think the questions I ask apply to semantic analysis? It looks to 
me like it's the parser's responsibility to tell which option is matched, and 
relaying this task to caller is not very attractive.

> So if you want to do semantic analysis in a generic way you have to
> test your input stream against your syntax rules (grammars), there may
> be several (your diferent option semantics), and test afterwards:
> - which of them was matched successful,
> - which results returned those successful matched grammars (which
> values were stored)
> - decide, if the semantics match too (i.e. was the matched long option
> really a allowed long option etc.)

I don't quite understand. What will parser do then? Are you saying that 
clients, instread of getting something like (option_name, option_value) 
pairs, should recieve something more complex?

> 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?

> in different ways and levels.
>
> It is certainly helpful, if the used parsing system has some methods
> for controlling the parsing process itself through the matched input
> sequence. And I think, I now understand, what you meant with 'dynamic
> parsing': a way of controlling the parsing rules used _during_ the
> parsing process itself. 

Please note that I have not used the word "dynamic parsing" at all.

> And because you do not know of any systems
> which provide such capabilities (YACC et.al. are static in this field),
> you decided to hand craft the command line parsing. 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.

> 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?

> Additionally, even such requirements as you formulate are one of the
> driving forces behind the development of such a library as Spirit. So
> please keep on pushing us in the right direction.

I'm not likely to be helpfull in "pushing" since I'm not using Spirit 
practically. I'm hoping to experiment with it some day in future.

- Volodya