Re: Any interest for a parser class?

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-16 14:14:19

Hi,

First of all I would like to say that IMO it is odd even to discuss 
an ability to use Spirit for generic command line parser. It's like 
use a canon to kill a fly. For one It is very expensive and heavy and 
also I should drag it all over the place.

--- In boost_at_y..., Dan Nuffer <dnuffer_at_c...> wrote:
> Schoenborn, Oliver wrote:
> >>-----Original Message-----
> >>From: David Abrahams [mailto:david.abrahams_at_r...]
> >>Sent: Tuesday, January 15, 2002 11:54 AM
> >>To: boost_at_y...
> >>Subject: Re: [boost] Any interest for a parser class?
> >>
> >>
> >>Will you submit spirit to boost? I want to see it here; I 
> >>strongly believe everyone will benefit.
> >>
> > 
> > Seems to me Spirit is targetted at a very special group of 
programmers.
> 
> 
> Nope.  Spirit is targetted at any C++ programmer who needs to do 
> parsing, which is most of them.  Even more so now in the age of the 
> internet and all it's protocols which need to be parsed.
So now iin any place where we were using tokenizer or regular 
expression I should pile up Spirit.

> 
> 
> > Spirit is an impressive piece of work. 

I completly agree with that.

> So impressive, actually, that I
> > don't want to use it because: 
> > 
> > - I need to know EBNF notation (or an approximation of it, if 
only to
> > understand the concepts); do I really want to learn a new 
notation just for
> > command line parsing, or even file parsing?
> 
> 
> If a programmer doesn't know EBNF, then they are missing an 
important 
> piece of knowledge, since it's the standard for computer langauge 
> definition.

Are you so sure? How is it in reallity?

> 
> 
> > - All I need is a toaster to *toast my bread*; not to also make 
it, tag it,
> > bag it and deliver it in my plate and gauge the toasting level to 
the bread
> > ingredients for the particular slice in the toaster.  
> > 
> 
> 
> Spirit is aimed to be a general parsing framework.  It is not aimed 
to 
> be a simple command line parser.  

That's the point.

> A command line parser would only 
> require a small portion of spirit's capabilities.  And, the library 
is 
> structured in such a way, that you only pay for what you use.

How much line of includes it will add to use a Spirit to parse a more 
or less complex command line?

> 
> I don't think that anyone is saying that having a simple to use 
command 
> line parser is a bad idea, because people should parse their own 
command 
> lines using spirit.  While this is certainly possible, it makes 
more 
> sense (to me anyway) to use spirit internally for the command line 
> parser implementation.  But, that still restricts the user to 
whatever 
> option format(s) the command line parser supports.

Why would I want to use the Spirit in the implementation? Rather than 
regexp or tokenizer? Is it that flexible that I can implement 
arbitrary parsing with it?

> 
> 
> > In other words, perhaps for really special applications that need 
super
> > advanced grammar (like building a compiler), Spirit would be 
worth the
> > effort for me to learn.  But frankly, a simple line parser based 
on
> > token-parameters with error reporting is sufficient in 99% of 
cases, fast to
> > build, extendable, robust, easy for everyone on the team to 
understand, even
> > someone who knows little about parsing.  It can't deal with 
grammar as
> > complex what Spirit can, but so can't the average programmer.
> > 
> 
> Learning how to use spirit is no different than learning a new API 
or 
> library.

I would assume that command-line parser still will have MUCH more 
simpler interface.

>  Spirit makes parsing incredibly easy.  Say, for instance you 
> had to write a function that would parse a complex number of the 
form: 
> real, (real), or (real,imaginary) and store the real and imaginary 
parts 
> in 2 doubles:
> 
> bool parse_complex(char const* str, double& real, double& 
imaginary);
> 
> Writing this by hand would probably take 20 lines of code or so.  
With 
> spirit, it's a one liner:
> 
> return (
> 	  real_p[ref(real)]
> 	| '('
> 	   >> real_p[ref(real)]
> 	   >> !(',' >> real_p[ref(imaginary)])
> 	   >> ')'
> 	).parse(str, str+strlen(str));
> 
> Well, maybe more than one line if you want it too look nice, but 
that's 
> one statement :-)

I would say that it will take at least 10 min for maintanance 
programmer to grasp what is written here (and this is not counting 
understanding how its working). I would implement the same logic in 2-
3 lines using tokenizer or regexp. Something like this:
token_iterator it( str, " \t," );

real      = lexical_cast<double>( *it++ );
imaginary = lexical_cast<double>( *it );

> 
> --Dan Nuffer

Gennagiy.