Re: Any interest for a parser class?

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 
here
> > 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 
filename.

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

> 
>     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 
accessable.
 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 
allows
>     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

Gennadiy.