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. _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison