Re: nested functions

Tommy Thorn <>
30 Aug 2006 14:11:00 -0400

          From comp.compilers

Related articles
nested functions (2006-08-29)
Re: nested functions (Tommy Thorn) (2006-08-30)
Re: nested functions (Ian Lance Taylor) (2006-08-30)
Re: nested functions (2006-08-30)
Re: nested functions (Tommy Thorn) (2006-08-30)
Re: nested functions (2006-08-31)
Re: nested functions (Tommy Thorn) (2006-08-31)
Re: nested functions (Marco van de Voort) (2006-09-06)
[6 later articles]
| List of all articles for this month |

From: Tommy Thorn <>
Newsgroups: comp.compilers
Date: 30 Aug 2006 14:11:00 -0400
Organization: Sonic.Net
References: 06-08-140
Keywords: code, design
Posted-Date: 30 Aug 2006 14:11:00 EDT wrote:
> From my understanding, a compiler uses
> 1. Lambda lifting where the nested function is hoisted to global level
> passing free variables through an env pointer or as explicit arguments.
> 2.Static chaining or displays which uses pointers to the corresponding
> stackframe in which the non local variable is defined.

It's rare to see mentioned in the same context as the former is
generally associated with functional languages and the latter

First, you can use lambda lifting in a procedural language, but all
variables that are modified by an inner procedure must be passed by
reference (see fx. Guy Steele's "ultimate lambda" paper). If that's a
significant number *and* the inner procedure can't outlive the outer
(can't "escape" it context), then you may be better of with static

Static chaining & displays for functional languages have been used
(see fx. Paul Appel's papers), but there are two problems: they are
prone to space leaks (in the case of the inner context surviving the
outer) and they are generally slower that passing just the needed
parameters in registers.

> One of my questions is
> whether lambda lifting cannot solve any cases which chaining/displays
> can only solve?.

I hope I answered that question. The answer is no (assuming the passing
by reference as needed).

> My next doubt is regarding the nested function support from GCC using
> trampolines. I could see that in case of function pointers of nested
> functions GCC was generating the code on the stack to move the frame
> pointer of the function in which the nested function is nested to ECX
> and then to do a jump to the nested function.
> My question is
> Whether GCCs support for nested functions is similar to nested function
> support in functional languages like haskell/scheme and do trampolines
> provide any advantage other than access time.?
  > I realise that you cannot return a nested func pointer and pass it
  > around since theres no way GCC associates state with the ptr.

Exactly! Trampolines are a sad compromise to implement closure-like
structures in a way that can co-exist with ordinary C (which expects
function pointers to point to code, not data structures). For language
implementations with direct support for closures, it's generally
better to use a structure with free variables and a function pointer
(very much like a C++ object and one virtual function).

There are exceptions to this which are hard to classify. Check
"Optimization for Lazy Functional Languages" by Urban Boquist for a
really all-out approach (and google "jhc haskell").


Post a followup to this message

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