Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!usenet.stanford.edu!usenet.osg.ufl.edu!news.lightlink.com!news.iecc.com!nerds-end From: Gene Newsgroups: comp.compilers Subject: Re: How to handle qualified identifiers such as x.y in a Pascal-like language Date: Fri, 24 Jun 2011 19:19:56 -0700 (PDT) Organization: Compilers Central Lines: 71 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-06-046@comp.compilers> References: <11-06-037@comp.compilers> <11-06-040@comp.compilers> <11-06-043@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1308972713 75916 64.57.183.58 (25 Jun 2011 03:31:53 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 25 Jun 2011 03:31:53 +0000 (UTC) Keywords: storage, symbols Posted-Date: 24 Jun 2011 23:31:53 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:172 On Jun 24, 2:56 am, Hans-Peter Diettrich wrote: > 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. Certainly there are lots of ways to implement. The one I proposed is not the very best for speed. It is rather good for space, though, and it's beautifully simple. Your proposal here though is I think incorrect. If we have procedure P: var x; procedure P: var x; ... P.x ... The P.x reference would conventionally be associated with the inner x. If you start searching for P.x outer scope first, you get the wrong one. > 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. You're right about P not being in its own dictionary. Each dictionary lies in a tuple (the pair I spoke of), where the other element is the identifier of the dictionary's scope. The identifier will also appear in the dictionary for the enclosing scope. The program identifier lies in no dictionary at all because it has no enclosing scope. With this convention I can't see a problem as long as procedure/program names inhabit the same name space as variables. Maybe an example would help me see your concern. I have actually used this technique to implement an assembler with scopes, and it worked quite well. > 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. You're right, but this language isn't C++. Nested procedures are allowed, and the s.x example shows that complete paths are not required. > 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. The dictionaries in the path are those for the static scopes currently open for parsing. When parsing a procedure nested N deep, you have N dictionaries. In a realistic program, N is often 1, maybe 2, seldom 3, almost never 4... In my experience id lookups are a trivial cost of processing compared to once-per-character operations like scanning. And in practice the most frequent case by far is simple id's in the inner scope, which need only one dictionary lookup. So you'd be unlikely to find this algorithm is a bottleneck. Thanks for the discussion.