Summary
Closures are extremely useful, no question, but they are hard to implement efficiently. I am considering implementing them in Heron but with auto-destruction semantics.

---

Advertisement

In many dynamic languages code blocks (a series of statements enclosed by curly braces) are first class objects along with nested functions. Within a code-block or nested function it makes sense for a programmer to be able to refer to variables outside of the codeblock's own scope. Doing so makes it a closure. The challenge here is that the language needs to assure that the lifetime of any objects referred to from the closure, last at least as long as that of the closure itself. This is a trivial problem in a garbage collected language, but considerably less so in a non-garbage-collected imperative language like Heron. A few options are available to me, but there is a nagging question:

Does the usage of closures lead to programmers inadvertently extending the lifetime of objects and if so is it a significant problem?

Some readers will surely say I worry too much, and in a garbage collected language, everything works out magically in the end. I am not convinced of that, and I think it is important to try and find an implementation technique which is efficient, and doesn't quitely make objects last longer than intended. I am trying to find a happy medium between efficiency, and also not be obliged to use garbage collection as a crutch for implementing closures.

As an alternative I am considering the possibility of auto-destruction semantics for closures. The idea is that if a nested function or code-block object refers to a variable, its lifetime becomes tied to the lifetime of the shortest lived object to which it refers. This approach means that closures can be passed to functions, but not returned from a function. However functions can still be passed from functions. So in a sense what I would be doing is somewhat limiting the usefulness of closures, but at the same time limiting the associated expenses.

There could be very good reasons for not doing things this way, and I would like to hear them. I am also wondering if there are alternative implementation approaches which don't require a garbage-collector which I can consider.

Talk Back!

Have an opinion? Readers have already posted 30 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.