From: | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 24 Jun 2011 07:56:07 +0100 |
Organization: | Compilers Central |
References: | 11-06-037 11-06-040 |
Keywords: | storage, symbols |
Posted-Date: | 24 Jun 2011 20:58:41 EDT |
Gene schrieb:
> When the language allows (as does yours) explicit scope paths, each
> dictionary D should also be paired with its identifier id(D) for the
> scope that caused it to be created, here function or program name. The
> lookup of a qualified id reference then proceeds right-to-left.
This IMO is the wrong way. Structured data types require left-to-right
evaluation of the qualified name, i.e. for P.x an identifier P would
be searched first, followed by a search for x in P's *local*
dictionary.
This is problematic with the intended approach, to refer to the
*current* module by its name (P), because the dictionary of P will
already be in the scope-stack, and this one does *not normally*
include the identifier P itself. Instead another (synthetic) outer
scope would be required, that only contains the P identifier, which
refers back to P's scope. Then the search for an global identifier x
would end up immediately in P's scope, of module-level identifiers,
while the qualified search had to go one entry deeper, to resolve
identifier P, which then refers to the (already traversed) P scope.
That's why e.g. C++ uses (AFAIR) "::" to denote the global (static)
scope, not the name of any module. This allows to start the search for
the following identifier(s) immediately in the correct scope, with no
chance for possible mismatches with identifiers P in some other active
scope.
In ObjectPascal (Delphi, FPC) every module (unit) has a public scope.
When a unit is "used", its public scope is pushed onto the scope stack.
This makes available all public external identifiers without
qualification. Newer Wirthian languages instead require full
qualification for references to external symbols, what reduces the
number of scopes to be searched, and eliminates errors that otherwise
can occur when the sequence of the used units is changed, for some reason.
> In your example to process s.x, work along the dictionary chain
> looking for the x. When it's found (in this case immediately) in a
> given dictionary D, match id(D) with s. If the path is longer, say
> P.s.x, you'd continue along the chain matching dictionary id's with
> path elements. If the whole path matches, you've found the right x.
> Otherwise keep looking for x's further down the chain.
This would require that *all* local dictionaries are in the search path,
what IMO doesn't make sense (performance wise), because a full match of
s.x only can occur in the s dictionary, regardless of how many other
scopes contain an x.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.