RE: [boost] Preprocessor Docs Comments

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-10-14 14:48:42

> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Gregory Colvin

> >> Right.  And I would find it easier to understand if I 
> could study its 
> >> BNF grammar.
> >
> > (I'm not sure if this is supposed to be sarcastic or not.)
> 
> Not.

Okay, my apologies.

> > It would be a large grammar.  The library acts like a programming 
> > language, but it isn't technically a programming 
> language--which gives 
> > it a lot more inconsistencies and special cases than a proper 
> > language.
> 
> I'm not clear on how it is "not technically a programming 
> language".  It has a syntax and a semantics, both of which 
> are difficult to divine from the documentation.  But I can 
> see that, given the basis in Cpp, a formal specification 
> would also be difficult.

It isn't technically a programming language.  It is a library built on
Cpp which is an extremely primitive programming language with arcane
(but exploitable) semantics.  To that end, the syntax of the library is
the syntax of the preprocessor itself, but with many facilities added to
make it a more usable language.  It also has many elements that are not
language-like facilities.  Rather, they are like library elements that
are built on top of the preprocessor itself and on top of other library
primitives.  Hence, "programming language" is not a perfect description.

The difficulty of a formal specification is the mechanics of the
preprocessor itself.  This gets even worse when buggy preprocessors are
taken into account because they don't follow the rules that the
preprocessor is supposed to follow.  The fundamental problem is one of
encapsulation.

> > (After all, it is built atop Cpp which drastically limits its
> > abilities.)  However, I suppose it is possible to produce a grammar.
> 
> That would be a worthy effort, even if it required some 
> hand-waving to 
> be
> tractable.

The problem is that a grammar cannot specify the semantic attachment
except is some very simplistic cases.  Without the semantic attachment,
the grammar is almost completely useless, as it becomes a huge
collection of invocation syntaxes (which are already there).  How would
you define the syntax for something as simple as the following:

#define CAT(a, b) PRIMITIVE_CAT(a, b)
#define PRIMITIVE_CAT(a, b) a ## b

?

The problem, even for something so simple, is that the possibilities
that would have to handled (for the grammar to be "formal") become very
large very quickly.

Regards,
Paul Mensonides