Re: Symbol tables and scopes

Hans-Peter Diettrich <DrDiettrich@compuserve.de>
6 Feb 2006 00:07:03 -0500

          From comp.compilers

Related articles
Symbol tables and scopes DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-28)
Re: Symbol tables and scopes david@tribble.com (David R Tribble) (2006-02-02)
Re: Symbol tables and scopes cfc@shell01.TheWorld.com (Chris F Clark) (2006-02-03)
Re: Symbol tables and scopes Peter_Flass@Yahoo.com (Peter Flass) (2006-02-03)
Re: Symbol tables and scopes gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-02-06)
Re: Symbol tables and scopes DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-06)
Re: Symbol tables and scopes DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-06)
Re: Symbol tables and scopes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-02-06)
Re: Symbol tables and scopes Peter_Flass@Yahoo.com (Peter Flass) (2006-02-07)
Re: Symbol tables and scopes alexc@TheWorld.com (Alex Colvin) (2006-02-11)
Re: Symbol tables and scopes cfc@shell01.TheWorld.com (Chris F Clark) (2006-02-11)
Re: Symbol tables and scopes cbarron413@adelphia.net (Carl Barron) (2006-02-12)
Re: Symbol tables and scopes DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-14)
[11 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich@compuserve.de>
Newsgroups: comp.compilers
Date: 6 Feb 2006 00:07:03 -0500
Organization: Compilers Central
References: 06-01-101 06-02-015 06-02-021
Keywords: symbols
Posted-Date: 06 Feb 2006 00:07:03 EST

Chris F Clark wrote:


<thanks for the snipped comments :->


> One thing worth noting is that in languages with explicit open scope
> (import) statements, the scopes do not necessarily exhibit stack like
> behavior.


I suspect that then the order of the imports defines the search order.
It's debatable whether a compiler should stop on the first match, or
whether it should search all scopes and warn on ambiguous names.


> I can easily imagine (and would potentially want to use) a
> language which has "search paths" that specify how a name gets
> resolved.


What criteria would you suggest then, for the grouping and placement of
symbol declarations?


The only useful answer I ever found, is a 1:1 correspondence of
definitions and their implementations. In this case every module only
imports required modules, so that a global search path is neither
required nor really helpful. Such conventions also eliminate the search
problem in the linker, which can use the compiler-detected module name
of every symbol, for his own name resolution.


> In that case, finding the string/hash-value is only a small
> part of the symbol look-up process. Once you know the hash value, you
> need to find out which instance of that symbol is relevant.


And this is just the point, why I see no use for a project-wide search
strategy. When ambiguous names exist, the programmer must have means to
specify the exactly wanted definition (qualified references), which must
have precedence over any search path.


DoDi



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.