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

From: Schoenborn, Oliver (oliver.schoenborn_at_[hidden])
Date: 2002-01-17 10:24:54

> Schoenborn, Oliver wrote:
> >>-----Original Message-----
> >>From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> >>Sent: Tuesday, January 15, 2002 11:54 AM
> >>To: boost_at_[hidden]
> >>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.

Double Nope, ie yep yep. Spirit is targetted at those who need a grammar,
not those who need parsing.  The simplest kind of parsing has such a simple
grammar that you can hardly say it has a grammar.  There

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

If a programmer doesn't know Lisp, Scheme, Prolog, Ada, Perl they are also
missing important pieces of knowledge, because every computer language,
whether it is for programming or parsing, has something new to teach.  That
doesn't mean everyone ought to know EBNF.  From reading the posts of people
who are familiar with Yacc, it seems that yacc-familiar people forget how
cryptic yacc is, and hence that in reality, few programmers are familiar
with it. 

Same perhaps with EBNF.  If I don't need a grammar, why would I bother
learning how to formally describe a grammar?  A big problem in software
maintenance is that code uses tools too complex for the average programmer.
When do I really *need* complex grammar?  Only when I need to express
complex relationships.  Yet software should keep relationships as simple as
possible.  Clearly, if you're building a compiler, you have no choice, you
*need* a complex grammar: the complexity of the grammar will allow for more
complex problems to be solved. But the average information parsing, this is
complete overkill, see below.

> Spirit is aimed to be a general parsing framework.  It is not aimed to 
> be a simple command line parser.  

Hmm, most other posts argued otherwise.

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

When are you really going to *need* such freedom of syntax?  Certainly not
in parsing a command line, or a configuration, or even passing data over the
internet.  In all such cases, the rule is simplicity, because simplicity
means usability: by the end user in the first two cases, and for the
programmer in the third.  Especially the third.  Data over the internet has
presumably already been parsed and for minimal bandwidth, should be encoded
as compactly as possibly, and not require reparsing on the other side.  Keep
your program and information exchange simple, and the user will actually use
the feature you make available on command line, config file, and programmer
will be able to extend and debug the information being exchanged over the
net.

Perhaps the reason for so much response to this thread is that my original
reply did not really say much:

- Don't let the availability of a tool (solution) dictate the solution to a
problem: keep the solution comensurate with the problem
- Plan for extendability of your application (not library) only so far;
requirements will change, complexity will change, people with important
knowledge will leave the project, understanding of the problem will augment
dramatically, etc
- Keep the solution as simple as possible: avoid grammar if you don't need
it, ie in command lines, config files, and internet data transfer; 
- Use the proper tool for the problem: if grammar *needed* by the *problem
domain*, use Spirit; 
- Use the proper tool for the problem: if *don't need* grammar, then use a
simple, straightforward, "grammar-less" parser; maybe that parser uses
Spirit in the background, but the parser-user shouldn't have to care, and
shouldn't even have to know anything about EBNF or regexp

My conclusion is that 
- I have nothing against Spirit, but I do against having the command-line
parser *be* Spirit.  Spirit is to command-line parsing what assembly is to
C++: lower-level of abstraction since grammar is not needed. 
- A parser class is needed, but should not require knowledge of EBNF or
regexp. And it is doable.

I actually look forward to the day where I have a problem that requires a
solution that involves Spirit.  So far, this hasn't been the case.

Oliver