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

George Neuner <gneuner2@comcast.net>
Sat, 25 Jun 2011 17:11:48 -0400

          From comp.compilers

Related articles
[4 earlier articles]
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)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l dot@dotat.at (Tony Finch) (2011-06-29)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-06-29)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-06-29)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-07-01)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l anton@mips.complang.tuwien.ac.at (2011-07-02)
[4 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Sat, 25 Jun 2011 17:11:48 -0400
Organization: A noiseless patient Spider
References: 11-06-037 11-06-040 11-06-044
Keywords: symbols, storage
Posted-Date: 29 Jun 2011 14:03:29 EDT

On Fri, 24 Jun 2011 13:58:23 +0200, "[Linux Magazine]" <uu3kw29sb7@snkmail.com> wrote:
>In practice people do not write procedures in procedures that much, and
>procedures in procedures in procedures are rare.


Nested procedures and 1st class closures are very common in functional
languages. C and its current popular variants don't permit them
(though C++0x has added anonymous lambda) and so, IMO, too many
programmers have no experience of their power. 1st class closures are
more general and more powerful than most object systems - closures
permit the construction of ad hoc objects that can bind arbitrary
functions to arbitrary data without the need for class definitions or
template objects.




>This also means that you need efficient access to global variables and
>variables local to the procedure currently being executed. Further the
>access to variables declared in the directly surrounding scope should be
>fairly efficient.


This goes without saying. However, it's fairly easy to arrange fast
access to nonlocals even in scopes several nest levels distant.


As has been mentioned, display is the canon method. Displays, though,
have a problem dealing with deep nesting ... which, admittedly is
rare, but not unheard of. Typically, the compiler will allow only so
many nesting levels and if you exceed that number, the compilation
fails.


Closure conversion - aka lambda lifting - is IMO a better method
because it can handle any nesting depth. It takes a bit more analysis
during compilation, but it is more flexible than a display.




>The rest just needs to work. You will do fine with an implementation
>where all procedures have direct access to its own variables and global
>variables, and variables declared in surrounding procedures may be more
>difficult to access.


Yes ... asymmetric access is acceptable for an academic exercise, but
not for a compiler that you would want others to use. I know the OP
is a novice compiler developer, but let's advocate learning general
solutions that will continue to work for more advanced projects in the
future.


George


Post a followup to this message

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