Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-18 13:15:09

--- In boost_at_y..., "joel de guzman" <djowel_at_g...> wrote:
> ----- Original Message -----
> From: "David B. Held"
> > P.S. It doesn't look like some posts I sent earlier made it, so
> > is my solution to your sample problem:
> [ snip ]
> > Now, granted, the substring matching isn't exactly elegant, but
it is
> > precise; and I'm sure someone with just a little more cleverness
than I
> > could come up with a more elegant solution. Now, let's see a
> > hand-rolled parser that does the same thing. Later, we can change
> > the requirements, and see which version is easier to maintain.
> Here's how I envision the CLA snippet David sent in:

Well, it's slightly better then nightmare presented before, but still
it has a whole bag of issues.

> string fname;
> string fext;
> int choice;
> int opt_repeat_count;
> rule<> filename
> = (+alpha)[ref(fname)] >> '.' >> (+alpha)[ref(fext)];

When defining CLA parser I do not want to know anything about

> rule<> option_name
> = substrings_p(
> "-roll",
> "-help",
> "-repeat_number"
> )[ref(choice)];

In many cases you have only ONE key per rule and won't be able
combine them in one rule (i.e. each argument rule suold be added

> rule<> option_param
> = choose_p(ref(choice),
> eps[&set_opt_roll],
> eps[&show_usage],
> int_p[ref(opt_repeat_count)]
> );
> rule<> cla
> = *(option_name >> option_param) >> filename;

It is ablutely unclear how it will work all together, i.e. choose
proper option and perform proper action.
 Couple more issues/questions:
 1. Will it work on any order of CLA provided?
 2. I do not want to implement show usage every time. Framework
should do it for me.
 3. I would want framework to keep CLA values instead of generating
tons of global veriables. How can I do this? Plus I need a means to
access argument by key in places where CLA parser definition is not
 4. How implement required/optional argument?
 5. How implement default values?
 6. How will it handle an errors? Including:
     a) wrong argument format: -repeat 3.5
     b) ambiguous argument: -r 3
     c) missing argument
 7. How long does it take to compile? Since this is not a compilable
version, could you provide the numbers for David Held version?

> Granted, some of these are yet to be written:
> { might be good additions to Spirit's utility parsers library :}
> 1) substrings_p: A utility parser that accepts strings and
> possibly ambiguous substring matches (simple left factoring
> parser code).
> 2) choose_p: A utility parser that chooses a production based
> on the first deferred integral parameter.

Now it seems that powerful Spirit right away can't even handle
simpliest CLA parsing needs. I can only imagine what will we need to
implement complete solution.

> The start rule is "cla". If cla is successful, all external
functions are
> called and all the correct parameters are extracted. It is easy to
> see how this may be extended further.

I do not want any external function for such simple CLA parsing. It
is generic enough to be a part of framework.

> --Joel


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