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

From: David B. Held (dheld_at_[hidden])
Date: 2002-01-18 14:19:09

-----Original Message-----
From: rogeeff <rogeeff_at_[hidden]>
To: boost_at_[hidden] <boost_at_[hidden]>
Date: Friday, January 18, 2002 12:21 PM
Subject: [boost] Re: Any interest for a parser class?

>[...]
>Well, it's slightly better then nightmare presented before, but still 
>it has a whole bag of issues.
>
>--- In boost_at_y..., "joel de guzman" <djowel_at_g...> wrote:
>> [...]
>>     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.

I can't help but feel you're missing the major points.  Clearly, Joel
added the filename portion as a convenience, which can be trivially
removed.

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

I don't think you understand what this rule is saying.  It's saying:
"Let's define all the option names, and then index them, putting
the current option index in the variable choice."  This is completely
generic, and should work for any option style at about the level of
complexity you suggested.

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

Allow me to clarify.  The option_param rule says: "Take the option
index in choice, and execute the semantic action at the appropriate
index in the following list."  So, for instace, when the parser 
encounters "-help" via the option_name rule, it puts 1 in choice.
Then, the option_param rule takes the 1 in choice, and executes 
the show_usage semantic action (it simply calls the function pointer
passed to it).  The cla rule glues it all together by saying: "We have a
set of 0 or more option(name, parameter) pairs followed by a 
filename."  Again, the filename is completely optional to include in
the cla rule.  It works just as well without.

> Couple more issues/questions:
> 1. Will it work on any order of CLA provided?

Yes.  It will correctly handle "-roll -help", "-help -rep 5", "", and
"-repeat 5 -help -roll".

> 2. I do not want to implement show usage every time. Framework 
>should do it for me.

The idea is not that raw Spirit code would constitute the entire CLA
framework.  The idea is that Spirit would be used to provide the
underlying parsing engine.  The actual CLA interface would be 
welcome to provide a default usage message, and Spirit could
trivially execute it as a semantic action.

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

Again, this would be the responsibility of the CLA library.  We are not
saying that a CLA library is unnecessary.  We are saying that a CLA
library should possibly be implemented with Spirit as the back-end
parser generator.  The CLA interface should allow the user to specify
options, and possibly store the variables for him/her until needed.
Doing so is quite trivial with Spirit as the parser-generator.  If you
absolutely cannot visualize how this is possible, I would be happy to
demonstrate with an example.

> 4. How implement required/optional argument? 

This is not a parsing issue.  The CLA library could perform this
trivially using Spirit.  The semantic actions for required arguments
could set a flag indicating they are present.  If, at the end of parsing,
the required arguments are not set, the CLA code could trivially
detect this.  Again, I could demonstrate with a code snippet if you
are having trouble seeing how easy this is.

> 5. How implement default values?

If the CLA framework stores values for the user, it could just as
easily store default values.  This is not a parsing issue.

> 6. How will it handle an errors? Including:
>     a) wrong argument format: -repeat 3.5
>     b) ambiguous argument: -r 3 
>     c) missing argument

This is entirely up to the CLA library.  Spirit provides almost any
imaginable exception handling scenario, from simple argument
list rejection, all the way up to specification of the failed parse
input and which rule the input violates.  The answer: You decide.

> 7. How long does it take to compile? Since this is not a compilable 
>version, could you provide the numbers for David Held  version?

I can't provide the numbers for VC++, since I don't have access to
it, but I'm sure on a typical computer, it probably takes several
seconds to compile.  But if you're worried that much about compile
speed over flexibility and maintainability, maybe you should consider
an assembler implementation instead.  I would be happy to examine
the merits of such an implementation if you are willing to provide
it.

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

Of course it can.  My example demonstrates that it does.  What
you have failed to comprehend is that Spirit is about power and
flexibility.  Joel merely observed that this is an area where even
*more* power and user flexibility can be offered.  I provided a
solution to your test in about 15-20 minutes.  I seriously doubt
Bill Kempf wrote his 150 lines of parsing code in under 30
minutes (but I could be wrong).  I'm sure the quality of Bill's code
is without question, but I certainly hope nobody suggests that it
is trivially extensible to arbitrary option formats.  While Vladimir
Prus claims that his code should handle all formats known to
him, I am wondering how easy it will be to define new formats.
I don't see where he has elaborated on that.  Without a dynamic
parser generator, I don't see how he can provide a high level
of format flexibility.

>I can only imagine what will we need to implement complete 
>solution.

Absolutely nothing more than exists now.  Unless you are a 
programmer that believes in high standards of code quality, and
like to see repetitive code refactored into elegant solutions.

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

When Joel says "external", he means "external to the Spirit
parser".  That doesn't mean it couldn't be internal to the actual
CLA library that implements the *parsing* portion using Spirit.
Does someone have to actually *write* a CLA library with
Spirit for you to see the benefits?  I would be willing to write a
small test library if you will also agree to write one without Spirit.

Dave