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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-18 14:05:46

From:	rogeeff [SMTP:rogeeff_at_[hidden]]
> 
> --- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > > From:	rogeeff [SMTP:rogeeff_at_m...]
> 
> > of the CLA component. However, if the CLA is implemented using 
> Spirit, then
> > any other parsing the programmer requires can use Spirit without 
> any further
> > impact on executable size (other than the parser-related logic they 
> write,
> > of course). 
> 
> It depends. Since Spirit is implemented inline every module that uses 
> it will be affected.

But the various template instantiations will be for common types like bool,
int, std::string, etc. Some things will not be well shared among the
different uses of Spirit, but many things will be built upon common pieces.

> > Obviously, if a custom -- not Spirit-implemented -- CLA were to
> > depend upon other standard/Boost components, then the same argument 
> holds;
> > this doesn't apply to Spirit alone.
> 
> Generic parser should not rely on ANY parser. It should not even need 
> not know about existance such beast like complex parser. It can 

That's a fundamental issue in this discussion. Joel, David Greene, and
others have said the opposite. Speaking from familiarity with parsers, they
see command line parsing as being well within the purvue of a parsing tool
like Spirit. You see this from the perspective of one without knowledge of
parsers, and think that a tool like Spirit is way too complex and powerful
for the job.

Let me share an experience I once had in this regard. Years ago, I wrote
code to parse HTTP headers for a proxy server. The code was getting pretty
hairy to deal with all of the cases and vagaries of the header format. When
I bit the bullet and started using a parser -- which involved a learning
curve, to be sure -- the parsing problem became almost trivial. Thus, while
I'm not a parsing expert, nor even well seasoned, I do see the value in
using a tool like Spirit to implement command line parsing.

An advantage to using Spirit, aside from simpler implementation, is
extensibility. *If* the use of Spirit were exposed in some way to the users
of the CLA, then they could benefit from its flexibility, too.

> handle fixed range of argument iddentification/value parsing rules 
> (but wide enough to cover most of CLA parsing needs) and provide an 
> abstract interface for user to add custom argument. This argument 
> encapsulate and implement somehow custon parsing logic, that include 
> custom identification and custom value parse. That's it. And let 
> everybody decide whatever they want to use.

Any interface that allows users to add custom argument handling exposes some
sort of parsing implementation. The information the parsing logic extracts
from the command line must be passed to the custom argument code for
processing. You can't escape the notion of a parser, even if it is written
without the aid of a tool like Spirit.

> > Besides, maintenance of those components is vastly
> > simpler if they all use Spirit for implementation.
> 
> We can use Spirit in any place where we need to comvert string to 
> value and no need to know lexical_cast.

Huh? Why would you use Spirit for type conversion?

> > Since neither a CLA component nor Spirit have been accepted into 
> Boost,
> > these discussions are purely academic.
> 
> CLA component is under development.

As is Spirit, though not specifically for Boost.

> > Let me summarize by saying that you should not be so quick to argue 
> against
> > what you don't know or understand. I'm not saying Spirit is the 
> right
> > solution, but it sounds very promising, as a separate component and 
> for the
> > implementation of a CLA component.
> 
> It sound misleading from generic CLA framework implementation 
> standpoint.

I don't understand what sounds misleading, but I hope you're beginning to
see that a general parser tool could be beneficial to implementing CLA
parsing.

Rob
Susquehanna International Group, LLP
http://www.sig.com