namespaces -- time to do something?

namespaces -- time to do something?

[Marc W. Mengel]

Well, now that egcs-1.0 is out, it seems to me it's time to do something about
namespaces for egcs-1.1.  Towards that end, I have a simple idea that I think 
will work which I'd like to toss out for folks to knock around.

Premise:
--------
Unless I am missing something, it looks like egcs *declares* namespaces 
okay, creates symbols in namespaces properly, and does fully-qualified names 
correctly, it just doesn't do "using" correctly.   

Proposal:
---------
If so, I propose we fix this by adding the following tokens to the grammar:

%token NAMESPACE_ID_ALIAS 
%token NAMESPACE_TYPE_ALIAS 
%token NAMESPACE_NAMESPACE_ALIAS

similar to TYPENAME, which carry around a tree-node for 
"namespace::name" instead of a type.  We then expand the symbol
to the fully qualified name when needed, like:

qualified_id : NAMESPACE_ID_ALIAS
	{ $$ = EXPAND_NAMESPACE_ALIAS($1); }

qualified_type : NAMESPACE_TYPE_ALIAS
	{ $$ = EXPAND_NAMESPACE_ALIAS($1); }

identifier : NAMESPACE_NAMESPACE_ALIAS
	{ $$ = EXPAND_NAMESPACE_ALIAS($1); }

Then "using" statements simply define the appropriate NAMESPACE_xxx_ALIAS
symbols in the current scope, similiar to how typedefs define a TYPENAME.
(By the way, how *do* typedefs define a TYPENAME?  I've tried to follow
through the code by hand to figure this out and keep getting lost...)

The only slightly painful part is when we see a "using xxx;" statement to
import a whole namespace, we have to make aliases for the whole list of 
symbols in the namespace...

This has one possibly confusing side-effect; if we have:

namespace fred {
	int a;
};

namespace jane {
	int b;
	using fred::a;
};

namespace paul {
	int c;
	using jane::a;
}

this could well succeed in making the "a" seen in namespace paul be actually 
fred::a, or fail, depending on how we define EXPAND_NAMESPACE_ALIAS()...
It's not clear to me which way this is supposed to work.

Marc

Re: namespaces -- time to do something?

[Jeffrey A Law]

  In message < 199712091617.KAA27851@fsui02.fnal.gov >you write:
  > Well, now that egcs-1.0 is out, it seems to me it's time to do something
  > about namespaces for egcs-1.1.  Towards that end, I have a simple idea that
  > I think will work which I'd like to toss out for folks to knock around.
namespaces is pretty high on the g++ todo list, but I can't guarantee that
it'll be done by egcs-1.1.

Jeff

Re: namespaces -- time to do something?

[Jason Merrill]

>>>>> Per Bothner <bothner@cygnus.com> writes:

>> Two "value fields" per id:  unqualified and qualified.  Both are lists.

> I suggest not using TREE_LIST nodes, though.  Instead add a
> lang_specific DECL_SHADOWS field, and use that to chain the
> actual decl nodes.  That makes it easy to find which decl
> is shadowing another.  It also saves the overhead of managing
> the TREE_LIST nodes.

Yep.  That's probably how we should handle unqualified lookup (along with a
nesting level index so that we know when to consult used namespaces).  It
doesn't work for qualified lookups, though.

> Another trick to consider:  Create a dummy declaration for each 'using'
> declaration.  In the Chill compiler, I called this an ALIAS_DECL.

Yep, that's what I was planning to do.

Jason

Re: namespaces -- time to do something?

[Per Bothner]

> Two "value fields" per id:  unqualified and qualified.  Both are lists.

I suggest not using TREE_LIST nodes, though.  Instead add a
lang_specific DECL_SHADOWS field, and use that to chain the
actual decl nodes.  That makes it easy to find which decl
is shadowing another.  It also saves the overhead of managing
the TREE_LIST nodes.

Another trick to consider:  Create a dummy declaration for each 'using'
declaration.  In the Chill compiler, I called this an ALIAS_DECL.
An ALIAS_DECL is a declaration that appears in one scope, but is an
alias for a declaration in some other scope (namespace).
We change lookup_name so that when it gets an ALIAS_DECL, it follows the
reference to the actual declaration.  (That could also be an ALIAS_DECL,
in which case you keep following the alias chain.)

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: namespaces -- time to do something?

[Olivier Galibert]

On Tue, Dec 09, 1997 at 06:44:01PM -0800, Jason Merrill wrote:
> I've already sent out my design for a rewrite of the lookup code, which is
> already ill-suited to C++.  I'll see about digging it up again.

Per Jason's request, here comes his post again.

  OG.

To: egcs@cygnus.com
From: Jason Merrill <jason@yorick.cygnus.com>
Newsgroups: cygnus.egcs
Subject: Re: Test run and a question

>>>>> "Lassi A Tuura" <Lassi.Tuura@cern.ch> writes:

> Mike Stump wrote:
>> > when support for namespaces
>> 
>> The standard answer is when you add support and get it in, then it
>> will be in.  :-)

> Talking as one who knows *very* little about gcc internals... How big an
> effort are we talking about here?

Significant.

> I would presume the template/namespace twistedness (Koenig rules) is the
> most difficult part...

Nah, that shouldn't be hard once the basic support is there.  Koenig lookup
just means you look up a function in multiple namespaces.  Maybe 10 more
lines of code.  The tricky bit is getting using directives right; the draft
says that a namespace nominated by a using directive is not searched in the
scope where the using directive appears, but rather in the lowest common
denominator of that namespace scope and the current scope.  The
time-consuming bit is going through and fixing all the uses of the current
name lookup stuff.  Here's a design document I put together for later use
in reimplementing scoping.  Anyone is welcome to work on it, or just
comment; I won't be able to work on it for quite a while.

Jason

-------
A more detailed design.  Feedback welcome.

Two "value fields" per id:  unqualified and qualified.  Both are lists.

The unqualified field is a stack of decls for the identifier, in order of
precedence.  Each entry has a level number.  Lookup that just finds types
or labels can scan the stack until it finds something of the proper
variety. Decls check for duplicates in the current level.  At the end of a
block, we walk the block's list of names and pop all the decls in the
current level for each name.  For methods, we set up a single binding level
for the class and its bases.  When defining a class, we set up a binding
level for the bases (using the same code), and another for the class
itself.  Lookup that ignores class scope can step over decls from class
scope (by checking a flag on the stack entry).

For push_to_toplevel we walk down the binding levels, storing the value of
the unqual field for each name used in any of the binding levels, and
skipping the decls lower than namespace scope.  In pop_from_toplevel we
just restore the saved values.

The qualified field is a self-modifying list of namespaces and
corresponding decls.  Perhaps the value field of each node should be a list
to allow for type and non-type values, or perhaps they should just be two
entries in the main list.

We also maintain a stack of used namespaces, along with the level number of
the using directive and the level number of the namespace in question.  If
unqualified lookup passes the level number of one of these namespaces, we
look up the name there before continuing up the unqual stack.  Each
namespace has a list of using-directives, and the nominated namespaces are
also checked.

Perhaps the used namespaces should also be noted in the binding level, so
we can look up a name in two steps: First, look at the first decl hanging
off the identifier.  Then walk the binding levels up to the level of that
decl to find any used namespaces.  If we only kept the stack, we would have
to walk the entire stack for each binding level.

Perhaps failed namespace-level lookups should be cached by adding a
NULL_TREE value for the namespace in question so we don't scan the whole
list of qualified bindings for a name each time we look it up.

Re: namespaces -- time to do something?

[Jason Merrill]

>>>>> Marc W Mengel <mengel@fnal.gov> writes:

> Well, now that egcs-1.0 is out, it seems to me it's time to do something
> about namespaces for egcs-1.1.  Towards that end, I have a simple idea
> that I think will work which I'd like to toss out for folks to knock
> around.

I've already sent out my design for a rewrite of the lookup code, which is
already ill-suited to C++.  I'll see about digging it up again.

> Proposal:
> ---------
> If so, I propose we fix this by adding the following tokens to the grammar:

> %token NAMESPACE_ID_ALIAS 
> %token NAMESPACE_TYPE_ALIAS 
> %token NAMESPACE_NAMESPACE_ALIAS

This seems unnecessary.  A using-declaration can be found using the same
lookup as any other declaration, and should use the same tokens.

> The only slightly painful part is when we see a "using xxx;" statement to
> import a whole namespace, we have to make aliases for the whole list of 
> symbols in the namespace...

No.  That's not how using-directives work.  In particular, names added to
the used namespace after the using-directive are also visible.  Also, the
lookup in the used namespace happens at the least common denominator of the
current scope and the used namespace.  Using-declarations are easy;
using-directives are the hard part.

Jason