Re: %prefix with C++ namespaces

[Joel E. Denny]

On Tue, 2 Oct 2007, Hans Aberg wrote:

> > > I do not think the leading "::"-issue is very important - but it would be
> > > nice
> > > showing one has given thought to it. :-)
> > 
> > So, I'm seeing no reason to disallow it.  If the user wants absolute
> > references, he should probably get absolute references.
> 
> It is OK with me whatever you do. Admitting a leading "::", and merely
> stripping it out in the "namespace" nesting seems fine.

Given this comment and given our discussion about how wrapping parser.cc 
in a namespace probably won't ever work, I think we agree that the leading 
"::" is redundant where Bison uses the user-supplied namespace to generate 
a namespace declaration.  That is, the outermost namespace is always the 
global namespace.

Where Bison uses the user-supplied namespace as a reference, I'm now 
thinking it should use the same approach.  That is, the outermost 
namespace should always be the global namespace.  The only way to be sure 
of this is for Bison to add a leading "::" if it's not already there.  
For example, the C++ skeleton #define's YYSTYPE to a name that starts with 
the user-supplied namespace.  If the user uses YYSTYPE in a scope other 
than the global scope, the reference might be ambiguous unless the leading 
"::" is there.

The YYSTYPE situation I've described may be rare, but I think it shows why 
this approach is cleaner.  If the namespace declarations must assume a 
leading "::", then so should the references.  In other words, `%define 
namespace "NS"' should consistently interpret NS relative to the global 
namespace.