Re: Representing Closures in C

SM Ryan <wyrmwif@tsoft.org>
23 Jul 2006 16:16:51 -0400

          From comp.compilers

Related articles
Representing Closures in C johan.tibell@gmail.com (Johan Tibell) (2006-07-21)
Re: Representing Closures in C haberg@math.su.se (2006-07-21)
Re: Representing Closures in C tommy.thorn@gmail.com (Tommy Thorn) (2006-07-21)
Re: Representing Closures in C johan.tibell@gmail.com (Johan Tibell) (2006-07-22)
Re: Representing Closures in C wyrmwif@tsoft.org (SM Ryan) (2006-07-23)
Re: Representing Closures in C haberg@math.su.se (2006-07-23)
Re: Representing Closures in C tommy.thorn@gmail.com (Tommy Thorn) (2006-07-25)
Re: Representing Closures in C tommy.thorn@gmail.com (Tommy Thorn) (2006-07-25)
Re: Representing Closures in C haberg@math.su.se (2006-07-25)
| List of all articles for this month |

From: SM Ryan <wyrmwif@tsoft.org>
Newsgroups: comp.compilers
Date: 23 Jul 2006 16:16:51 -0400
Organization: Quick STOP Groceries
References: 06-07-058
Keywords: functional

"Johan Tibell" <johan.tibell@gmail.com> wrote:
# > > [There's certainly been a lot of work on this. Seems to me you basically
# > > want to carry a symbol table along with each expression. -John]
#
# I threw together a crude and probably incorrect interpreter tonight. I
# store bound variables in a linked list that's carried along with the
# closure.


A closure is a dynamic stack of scopes; a scope is a mapping (or
dictionary) from identifiers to values. There are many ways to
implement a scope mapping: linked list of identifiers, self organizing
list, sorted tree, hash table, etc. If you don't need a sorted
traversal, you can get a hash table implementation out of a library on
many systems.


The stacked scopes is just the innermost scope defining an identifier
is used. You can maintain an actual stack of scopes; or you can have a
scope be a dictionary of an identifier to a stack of values, or you
can smash the scope stack. One advantage of a stack of scopes is ease
of sharing outer scopes amongst closures: you then end up with a tree
of scopes, each closure being a path from a leaf to the root. This
also means you can safely use reference counts to decide when a scope
is garbage.


The really big issue is when the identifier value is a variable on the
procedure stack, because procedure stack frames are automatically
recoverred on procedure exit of most languages unless you change the
language implementation. This doesn't occur in applicative language
because the identifier value is never a variable. Algol-68 could have
supported closures because you can use heap variables instead of local
variables.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
What kind of convenience store do you run here?


Post a followup to this message

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