Re: Symbol tables and scopes

I wrote:
C> One thing worth noting is that in languages with explicit open scope
C> (import) statements, the scopes do not necessarily exhibit stack like
C> behavior. I can easily imagine (and would potentially want to use) a
C> language which has "search paths" that specify how a name gets
C> resolved. In that case, finding the string/hash-value is only a small
C> part of the symbol look-up process. Once you know the hash value, you
C> need to find out which instance of that symbol is relevant.


Gabriel Dos Reis <gdr@integrable-solutions.net> asked:


R> is the "using directive" found in C++ such an example?


I don't know enough of the details of that aspect of C++ to say for
certain. There are features of templates where names can be
disambiguated to different definitions depending on the context,
meaning a simple stack search is not appropriate. I'm not certain how
this interacts with namespaces (or if it even does).


As Hans-Peter Diettrich <DrDiettrich@compuserve.de> wrote:


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


BTW, searching all scopes is one thing that makes imports not
stack-like. If one requires warning (or disambiguation) on names
imported from more than one source, one cannot stop on the first walk
back up the stack. Another, thing would be explicit scope non-nesting
scope terminations, (i.e. "close scope" statements).


As, glen herrmannsfeldt <gah@ugcs.caltech.edu> noted (but which I
didn't quote), pl1 had interesting semantics for structure names where
partially qualified names could disambiguate things and required more
than a simple stack-like look-up. Verilog (my current nemesis) has
the same behavior with its own quirks.


D> The only useful answer I ever found, is a 1:1 correspondence of
D> definitions and their implementations. In this case every module only
D> imports required modules, so that a global search path is neither
D> required nor really helpful.


I agree that there ought to be a way for the user to discover the
exact correspondence between definitions and implementations and to
preserve such correspondence reliably in the face of changing
standards, implementations, and libraries.


However, I find that giving a method of explicitly qualtifying
references and then requiring the users to explicitly qualify their
references is often used as a cop-out solution. I don't want to have
to explicitly qualify a bunch of existing imported names in my
environment just because I decided to use a new imported library (or a
new version of some library is now available). I also don't want to
have to explicitly list which names are coming from which library,
since the library providers might change that.


Not so long ago the C++ standard-holder did just that when they moved
a bunch of previously unqualified names into the "std" namespace. I
want to be protected from just that occurrance, so that my currently
working software keeps working in the presence of evolving standards
and implementations.


This is why I want user configurable search rules. I import a set of
search rules to get one set of functions. (Note, I import a set of
search rules not simply modules, so that the definers can move names
around within their rules without affecting me the end user.) I might
import another set of search rules to get other functions. I would
like to be able to decide which ones I want to take precedence (or
where I want explicit disambiguation). I would also like a way to get
back a copy of my program explicitly disambiguated in a form that is
acceptible as input to the process in case I want to "freeze" the set
of disambiguations (or to verify that the names disambiguated to what
I expected when things seem awry).


If done right, search rules allow one to adapt the software to changes
in the environment by changing one central location. They also allow
one to have a conveniently controlled environment, where one can use
simple names to refer to the definitions one wants. Moreover, it
usually makes it easy to expand or change that list of definitions.
They are not a panacea and can be abused, but they do make some things
easier.


Just my opinions,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

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