Re: How to handle qualified identifiers such as x.y in a Pascal-like language

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Fri, 24 Jun 2011 07:56:07 +0100

          From comp.compilers

Related articles
How to handle qualified identifiers such as x.y in a Pascal-like langu noitalmost@cox.net (noitalmost) (2011-06-20)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l torbenm@diku.dk (2011-06-22)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-06-22)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l gene.ressler@gmail.com (Gene) (2011-06-22)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l noitalmost@cox.net (noitalmost) (2011-06-23)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-06-24)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l uu3kw29sb7@snkmail.com (\[Linux Magazine\]) (2011-06-24)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l gneuner2@comcast.net (George Neuner) (2011-06-24)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l gene.ressler@gmail.com (Gene) (2011-06-24)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-06-25)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l gneuner2@comcast.net (George Neuner) (2011-06-25)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l noitalmost@cox.net (noitalmost) (2011-06-29)
[9 later articles]
| List of all articles for this month |

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



Post a followup to this message

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