Boost logo

Boost :

From: HartmutKaiser_at_[hidden]
Date: 2002-01-21 09:04:57

Vladimir Prus 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.

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

These semantic actions can do whatever you want, i.e. store a (matched)
value, do some calculation, call a function etc.

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.)

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

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);

i.e. a number containing a count followed with exactly 'count' items)
but that's certainly not enough. But those utility parser are in
development (switch like structures

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.

Regards Hartmut

Boost list run by bdawes at, gregod at, cpdaniel at, john at