From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20074 invoked by alias); 17 Sep 2002 19:18:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20067 invoked from network); 17 Sep 2002 19:18:07 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 17 Sep 2002 19:18:07 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8HJI6v12379; Tue, 17 Sep 2002 12:18:06 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: Andrew Cagney , gdb Subject: Re: struct environment References: <3D86DE18.6030003@ges.redhat.com> <20020917134057.GA26237@nevyn.them.org> From: David Carlton Date: Tue, 17 Sep 2002 12:18:00 -0000 In-Reply-To: <20020917134057.GA26237@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00231.txt.bz2 On Tue, 17 Sep 2002 09:40:57 -0400, Daniel Jacobowitz said: > On Tue, Sep 17, 2002 at 03:47:36AM -0400, Andrew Cagney wrote: >> - Am I correct to think that the objective is to create a directed >> acyclic graph of nametabs and have lookups search through each in turn. > Well, sort of. It won't be a DAG necessarily (I think that mutual > "using" statements are legal in C++; I remember a GCC bug involving > them was fixed not long ago), and it will be somewhat complicated > figuring out which ones to look up (namespace links are different > than block scope links). That last parenthetical comment is important. (And I hope it will only be 'somewhat' complicated...) If you have a C++ file like this: using namespace A; int foo() { // body of function } then 'foo' gets added to the global environment, but the 'using namespace A' doesn't affect the global enviroment, just this particular file. (E.g. it modifies the search rules in the body of the function.) So 'using' statements only modify symbol lookups, they don't modify symbol definitions. In contrast, the curly braces around the body of the function modify two things: they modify symbol definitions (since new variables defined in the body _aren't_ visible in the global environment), and they also modify symbol definitions. So you have to be able to deal with language constructs that only modify where symbols are looked up as well as language constructs that modify where symbols are looked up _and_ where symbols are added; and, in the former case, you have to make sure that you only modify where symbols are looked up in one particular chunk of the code, not in the entire enviroment where symbols are currently being added. (And, incidentally, 'using' isn't the only way that name lookup can get modified in this sort of way.) Because of this, I don't think it's very useful to conflate these two sorts of relationships between environments and just talk about a DAG. There should be a tree reflecting the block structure (which we already have, of course); and there should be some other data structure reflecting additional symbol lookup rules. And I'm not sure yet exactly what that other data structure should look like, or how it should interact with the block structure tree. Or, for that matter, whether either kind of data should stay within struct block or move within struct dictionary. (I'm leaving everything in the former until I'm sure it should move.) Obviously I need to read the relevant parts of the C++ standard before working on namespaces proper. For what it's worth, I think the relevant buzzword is 'Koenig lookup', but I could be wrong. And I just hope and pray that other languages with complicated name lookup rules use the same mechanisms as C++... David Carlton carlton@math.stanford.edu