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

From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-17 03:26:56

----- Original Message ----- 
From: "rogeeff" :

> What I meant is adding line #include "boost/spirit/spirit.hpp" in 
> your code immidiately produce ~600k of include files ...

The core is extremely small. We are organizing the layers now
and the spirit-core will be a lean-mean machine.

> * I was not able to find out portability report for Spirit. Since CLA 
> parsing is very basic facility, I should be able to compile it on 
> majority of compilers.

Metrowerks CodeWarrior 5.3 ***
Metrowerks CodeWarrior 6.2 
Borland C++ 5.5.1 
GCC 2.95.2 / 3.0x
Edinburgh Portable Compilers EC++ 5.3.2 
Intel Compiler 5.0 
MSVC version 6.0 ***
Comeau

*** V1.1 (V1.2~V1.3 is in the porting stage)

> * I could be wrong, but Spirit seems to be static compile-time 
> facility. I.e. I can't load CLA scheme dynamicaly or read it from 
> configuration file. Also how would it distributed definitions?

Sure you can! And you can still use spirit to parse the config file.
The config file can be as complex as you want, even XML.

> Spirit is a parser framework. Command line/Configuration processing 
> is a different realm with diffrent rules and priorities. I do not say 
> that one can't implement concrete CLA parser using Spirit. I just 
> question it'a ability to be used for generic framework.

??? Sorry, I do not understand what you mean.
 
> I agree with you. Every task has it own tools to solve it. More over 
> I also thinking about using Spirit for some of my parsing purposes. 
> It I would be able to compile it with my compiler ;-))

Spirit was originally designed for small to medium parsing tasks.
Command line parsers / internet protocols / file I/O etc. It is 
a perfect fit for parsing command lines, IMO.
 
> I would assume that thare are a lot of programmers that never had a 
> need to parse a formal grammar that complex that they would need YACC 
> or even simply knowledge of EBNF, though I do not question it's value.

EBNF is not meant only for complex grammars. If a programmer can grok
regular expressions, EBNF comes naturally.

> > You missed the point.  Spirit is flexible enough for many, many
> > parsing tasks, including implementation of the command-line parser.
> > One need not expose the Spirit interface to the programmer.  But it
> > makes a great deal of sense to me to use Spirit to do the actual
> > parsing.
> 
> I did not get it. What will provide an interface and where do you see 
> a place for Spirit? Specifically, with example.

Example:

    config-file ---> spirit ---> cmd-line-parser
    cmd-line ---> cmd-line-parser ---> program

A config-file specifies the behavior of the command line parser. It
can be simple or quite complex such as XML. Spirit parses that and 
generates a command line parser. The command line parser
does its work given a command line.
 
> There are several questions:
> 
> 1. How portable it is?

Very. See above.

> 2. How it affect compilation time?

As mentioned, spirit core will be isolated with V1.4. That
should be good enough for many small parsing needs.

> 3. How it affect code size?

Tight. Almost the same as a hand-coded RD parser.
And you don't pay for what you don't use.
 
> How about error handling? what if I want to ignore an error and 
> proceed. How one-liner below would handle it?

You can ignore errors if you want to. You can also
use exceptions and error handlers.
 
> Id did not say that I agree with any flexibility tradeoff. But the 
> interface should be as simple as possible: 1. plug parsing rule, 2. 
> parse, 3. get value. ...

Sure, that's doable. You can make a language as simple
as you want. No need to learn EBNF. See above. You
call the shots.

The thing is, you are just looking at the first level parsing
where EBNF is the language. The framework does not preclude
the client from building parser-parsers or even parser-parser-parsers
each using a language of its own. For instance, someone wrote an
EBNF dynamic parser using Spirit as the code generator. Then
he's writing one that accepts Spirit EBNF parsed by Spirit to
produce Spirit, thus, a Spirit parser-parser that parses, ummm
Spirit.

> 
> How many programmers are familiar with YACC and how many would use 
> CLA parser? 

Much more than programmers familiar with a custom
command-line config file format, I am sure. But then
again, that's not the point. You *can* use your own
custom command-line config file format.

> Wait, wait. It is not boost tokenizer (it my simple token_iterator I 
> am using for old Sun compiler that can't handle boost one). Given the 
> definition 
>     token_iterator( const_string string_to_tokenize, 
>                     const_string delimeters)
> 
> it should be pretty easy to unerstand what is written there. 

Again, (see my other post), the behavior is not the same. 
Dan's micro grammar parses:

 r or (r) or (r, i)

Use the comma and the parens as delimeters?
But then such an approach will allow invalid inputs such
as: 1,)(2. or ,,1)2))). A tokenizer does not know anything 
about structure.

--Joel