|
|
Re: Macros and Type-Systems
|
Posted: Oct 4, 2005 6:56 AM
|
|
> Even if you don't go all the way to a multi-stage
> language, or something like that, what you've shown in the
> examples is typically called unnamed functions or lambda
> functions, which I'm sure you're aware of.
The proposed Heron macro is similar but does not have a stack frame and, at least for now, can't be recursive. The macro is always inlined.
> These exist in various forms in some other languages as,
> well, such as in Smalltalk, where you can pass a code
> block to a method. It can also be done, to some extent
> (and with a "ton" of library code) in C++ with
> Boost.Lambda.
>
> A challenge with lambda functions is references to
> variables outside the function, and managing their
> lifetimes (such as if you store a lambda function for
> later use, such as a callback).
One solution to this problem I have been exploring is that closures (my definitions: functions referring to variables outside of the scope of the function) as having a lifetime which is equivalent to the shortest lived object referenced.
So:
{
int x;
{
def f() {
return x;
}
f(); // fine
}
f(); // fine
}
f(); // runtime-error
I mention this approach in the thread "Musing about Closures" http://www.artima.com/forums/flat.jsp?forum=106&thread=129705 . This seems to be a novel idea, but I am still trying to ascertain the expressive power of it. It is not as powerful as a closure in many functional languages, but IMO it is still very useful.
> Java "simulates" somewhat
> such lambda functions/closures with anonymous inner
> functions, where the compiler inserts references to
> external variables, where needed, in the generated code,
> and lifetimes being handled with the garbage collector
> (actually, it only handles storage, since GC in effect
> simulates "infinite lifetime").
The "infinite lifetime" of objects in a GC, is exactly something I want to avoid in Heron at all costs. The idea of a programmer unintentionally extending lifetimes of objects, and having to do extensive post-analysis to identify object lifetime issues, is a nightmare I want to avoid.
|
|
Previous Topic
