Why not expose activation records as data types?

Question

Scoped languages tend to store the local variables of a given scope or function together in a data structure known as an activation record. Stack frames are examples of instances of activation records. Not all activation records are part of a stack; for example, in ECMAScript/JavaScript they are garbage collected and you can re-enter a scope through a function object.

Does any strongly-typed language exist with activation records as first-class objects, even with severely limited capabilities? What considerations does this tend to raise? For example, this function:

void f( int i ) {
    int j = i + 3;
    {
        int * q = & j;
    }
    {
        char r = 'z';
    }
}

… could map to this data type:

struct f_activation {
    int i;
    int j;
    union {
        int * q;
        char r;
    };
};

This is just an example; an optimizing compiler wouldn't want to nail down such a restrictive mapping.

Assembly language programmers often declare activation records using the same record directive as other data types. TCL has the uplevel command which is sufficient to treat the scopes of calling functions as objects. (I have seen this done. No joke.)

Context of the question: The C++ community is trying to add coroutines to a future language revision. C++ already has a popular design pattern, "function objects," and many would like paused coroutines to act like objects too, ideally with serialization and clean forced-termination.

I'm not looking for a laundry list, but for past experience with this language design direction. However, I'm happy just to get references so I can do deeper reading myself.

Answer 1

Yes, but not quite in the way you're thinking of. This is an integral part of closures, which many languages make use of. Closures are implemented by moving part or all of the activation record of the enclosing method into a new object, which is then passed somewhere and a method is called on that object, which can access the data in the closed-over activation record.

In at least one such language, Delphi, it's possible to use RTTI to get at the members of the closure's activation record, which would be useful for the serialization use case noted in the question. Similar things can probably be done in .NET languages with reflection.

Answer 2

Interesting question (which I studied in my 1990 PhD thesis, BTW). I'll rather speak of call frames (on the call stack) instead of activation records (which IIRC are relevant for nested functions displays).

It is quite related to continuations, and there are several languages reifying somehow continuations (notably Scheme). Most of the time continuations are considered abstract (e.g. in relation to CPS or call/cc); sometimes there are inspectable (or even mutable). Read also about dynamic software updating, persistence, application checkpointing, Lisp machines.

Read also old A.Appel's book Compiling With Continuations & his old paper Garbage Collection Can Be Faster than Stack Allocation. Read the Flanagan & al paper Essence of Compiling With Continuations.

Read C.Queinnec Lisp In Small Pieces book which explain various strategies and tradeoffs related to your questions.

Notice that closures (used for function abstractions and anonymous functions) are often heap allocated (and they usually want an efficient garbage collection implementation). Look into Ocaml.

Several implementations of languages are able to introspect the call stack, at least for debugging purposes, a minima like the GNU libc backtrace functions. Look for instance into the JVM (see this question) and the JPDA. IIRC, Smalltalk has explicitly reified call stacks.

A practical issue is efficiency (in particular when you have genuine machine code, e.g. produced by JIT techniques), since most calling conventions do not require that all arguments go thru the processor stack, and a few of them go only thru registers (and might not even be spilled on the stack). Efficiency consideration and compatibility with existing ABIs and calling conventions could explain lack of standard call-stack introspection techniques (since efficient register allocation is hostile to full stack introspection).

BTW, a precise garbage collector is in need of call stack introspection (since it needs to trace local variables pointing to GC-ed values or objects). So look also into some implementations of Scheme entirely or mostly written in Scheme (e.g. Bones, S48, Chicken).

The SBCL implementation of Common Lisp is also able to introspect call stacks (and both its debugger and its compiler is written in SBCL).

Look also into Lua & Neko & Parrot. IIRC, their bytecode VM is introspectable (including the stack[s]).

Look also into Lisaac project.

See also the nearly obsolete setcontext(3) (on Linux and some other Unixes) & longjmp(3). Notice that C++ destructors and exceptions (and threads) are related to the call stack.

Read the technical appendix of J.Pitrat's book Artificial Beings, the Conscience of a Conscious Machine and his blog which have several explanations about why introspecting the call stack can be practically useful.

BTW, my MELT stuff (a Lispy domain specific language to customize GCC) nearly has introspectable call stack (the internal implementation has it, but I might not yet have exposed it).