Re: Symbol tables and scopes

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

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