Re: [boost] [spirit] Library naming and sub-libraries (was: Proposal: Add Loki Library's SafeFormat to Boost:)

Subject: Re: [boost] [spirit] Library naming and sub-libraries (was: Proposal: Add Loki Library's SafeFormat to Boost:)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-01-02 16:51:54

> Joel de Guzman wrote:
> >
> > You can disagree as much as you want. You can rationalize as much as
> > you want. Well, programmers tend to do so. As far as I am concerned,
> a
> > name is a name and I, as author, reserve the right to naming my work.
> 
> Now that's a very "constructive" approach, I must say. Yes, you may
> name
> it as you like, but if the name is nothing but a funny word to you, you
> just push away users of your library. Unless you don't care about that,
> that is...

Spirit got well known all over the world even while being named with the
'funny' name. 
IMHO, this whole issue mainly is a matter of taste, so I doubt we'll find
any consensus.

> > Are you suggesting that Spirit be renamed to Boost Parsing Library?
> > Sorry, but no thanks.
> 
> I understand that it's too late to rename the library now. However, I'd
> like to ask to reconsider naming of yet to be released libraries, like
> Karma or Qi (or what was it?).

Just read the first paragraphs of the 'Introduction' in the docs and you'll
know. That's something you'll have to do anyways, even if the library has a
'functional' name.

> >> The formatting capability is a brand new domain, and therefore it
> >> should be extracted as another distinct Boost library. It may build
> on
> >> top of Spirit, it may use the same coding guidelines, but it should
> a
> >> be separately reviewed library in its own directory under boost.
> >
> > I disagree. Karma was never advertized as a top-level Boost Library.
> 
> It should, IMO.

Think about this again and you'll see Joel's point. 

Karma is based on the idea, that a grammar usable to parse an input sequence
may as well be used to generate the very same sequence in the output. Qi and
Karma use exactly the same description of the (expected/generated) format -
a grammar.

> > It is a Spirit sub-library. Parsing and generation are two sides of
> > the same coin.
> 
> These tasks are the opposite. I don't see why they should be mixed in a
> single library.

For the same reason as Boost.Serialization consists out of two parts:
serialization and de-serialization.

> >> The situation with so-called sub-libraries, IMHO, is a bad thing to
> >> allow in Boost. This turns libraries like Spirit into a playground
> >> where actually live several libraries with totally different classes
> >> of tasks being solved. What's worse, these libraries don't get
> >> reviewed (which
> >
> > Phoenix and Fusion got reviewed. They were once sub-libraries under
> > Spirit. Proto got reviewed. It was once a sub-library under
> Xpressive.
> 
> How long did they exist as parts of Spirit? Were they approved to be
> included as parts of Spirit and/or recommended/allowed to be used
> independently? Why would Spirit contain a duplicate for Lambda and how
> they can (or should they?) coexist gracefully in the user's code? Which
> one should be used by default? These questions may sound silly to you,
> but I recently happened to write an article about Boost libraries, and
> such questions took a lot of time to answer. I believe, every developer
> exploring Boost will stumble on such questions sooner or later.

All these question do not have any connection to the naming issue related to
which you're trying to make a point.

> >> may be a tempting reason to add such libraries), they duplicate
> other
> >> existing libraries in Boost (which confuse users), and they honor
> >> further duplication in the upcoming libraries (which wastes time of
> >> these libraries' developers).
> >
> > Which upcoming libraries are you referrring to? Could you be more
> > specific?
> 
> I was saying in general. The current state of code in the repository
> introduces the "common practice" which can be followed by the new
> library authors.

Boost is a very dynamic collection of libraries. And the existing libraries
provide an excellent playground for the library authors to improve what's
there and to add new capabilities. It was a Boost guideline from the very
beginning, that a library is reviewed once and afterwards the authors are
free to develop new versions of this library without further review.

This approach has lead to the development of Proto (former part of
Xpressive) and Phoenix and Fusion (former parts of Spirit). IHMO, this is a
very productive way of gaining new insights and developing useful libraries.

Regards Hartmut