Re: Symbol tables and scopes

On 6 Feb 2006 00:07:28 -0500, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:


> Chris F Clark wrote:
>
> (snip)
>
> > I can easily imagine (and would potentially want to use) a
> > language which has "search paths" that specify how a name gets
> > resolved. In that case, finding the string/hash-value is only a small
> > part of the symbol look-up process. Once you know the hash value, you
> > need to find out which instance of that symbol is relevant.
>
> One interesting case is PL/I, which allows partial qualification
> for structures. True ambiguous cases are not allowed, but cases
> that could be considered ambiguous at different nesting levels
> are allowed.


So does/did COBOL. Except that it calls them 'group's and writes the
subpath in reverse order: ZIP-CODE OF HOME-ADDRESS OF CUST-REC. But
since COBOL originally didn't have nested routines at all and still
makes them rather clumsy, it encourages large routines with lots of
functionality and lots of variables, many of which are large
complicated structures often with similar elements, increasing the
likelihood of collisions/ambiguities, resulting in many burnt-once
programmers who always fully qualify everything.


- David.Thompson1 at worldnet.att.net

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