Related articles |
---|
[4 earlier articles] |
Re: Number of compiler passes dwashington@gmx.net (Denis Washington) (2008-07-25) |
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-25) |
Re: Number of compiler passes gneuner2/@/comcast.net (George Neuner) (2008-07-25) |
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-26) |
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-27) |
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-07-28) |
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-07-28) |
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29) |
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29) |
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29) |
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29) |
Re: Number of compiler passes barry.kelly@codegear.com (Barry Kelly) (2008-07-30) |
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-01) |
[2 later articles] |
From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Mon, 28 Jul 2008 16:47:02 -0400 |
Organization: | Compilers Central |
References: | 08-07-041 08-07-044 08-07-048 08-07-058 08-07-061 |
Keywords: | symbols |
Posted-Date: | 29 Jul 2008 19:21:38 EDT |
On Sun, 27 Jul 2008 19:06:28 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
>George Neuner wrote:
>(snip)
>
>> As long as non-local variables are transitively in the lexical scope
>> chain of the function that uses them you can still gather all the
>> declarations in one pass. If they're not, you have a language that
>> will be error prone and confusing to use.
>
>> The simplest way to do it is to organize your symbol "table" as a
>> stack of lists[*]. You attach a local symbol list to each function's
>> definition node in the AST.
>
>I think that is fine, but some languages and language features
>complicate the problem.
>
>One interesting feature (though some might disagree on
>whether it really is a feature) is partial qualification
>for structure references in PL/I.
>
>Referencing a variable in a structure only needs enough
>qualification to be unambiguous. It gets more interesting
>with nested scope when a name could agree with partial
>qualification at more than one level. I believe it works
>such that, given the stack of lists as you indicate, you can
>go up the list and take the first one that agrees, within
>partial qualification, with the given symbol.
In practice, I think partial qualification is only an issue for
languages with latent or no typing.
Given typed variables and record fields, the expression always has to
type check correctly. The only sticking point is resolving a union of
record types - if the definitions are structurally compatible to the
required level, it doesn't matter which definition you choose. If
they are not structurally compatible, the access can't be resolved
even if the explicitly named field happens to be end type compatible
in all definitions.
As for shadowing definitions, I would simply go with the inner one. I
can see some minor utility to searching until you find a definition
that works, but I think it would make the language very confusing to
allow simultaneous access to multiple types of the same name.
>That makes it relatively easy for compilers, and means
>that a change at a higher level of nesting won't change
>the meaning of a name at a lower level.
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.