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

From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-18 09:23:04

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

    string  fname;
    string  fext;
    int     choice;
    int     opt_repeat_count;

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

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

    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;

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.

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.

--Joel