Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: How to handle qualified identifiers such as x.y in a Pascal-like language Date: Fri, 24 Jun 2011 07:56:07 +0100 Organization: Compilers Central Lines: 50 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-06-043@comp.compilers> References: <11-06-037@comp.compilers> <11-06-040@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1308963522 51359 64.57.183.58 (25 Jun 2011 00:58:42 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 25 Jun 2011 00:58:42 +0000 (UTC) Keywords: storage, symbols Posted-Date: 24 Jun 2011 20:58:41 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:169 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