Then you could pass around a reference to it that has linear ownership semantics, so that when your reference goes out of scope you can delete the target object. This requires that copying the reference copies the object on the heap, keeping the system of closures acyclic.

With suitable optimizations, you should be able to avoid constructing that heap based closure most of the time.

Copying costs become proportional to the size of the environment this way, and while you could go with a lame reference counting solution, that blows up in your face when you want fast multithreaded performance and start dealing with cache thrashing and may inject cycles and space-leaks if you aren’t careful.

“Downward” closures are possible to compile without GC (Ada 2005 now has them), but upward closures cannot without some tradeoffs. For instance, copying closure environments instead of passing by reference, and distinguishing function pointers without an environment from closures. As for how to implement this copying, well you compile your higher-order language to a first-order intermediate language which exposes representation for the code generation phase.

Another alternative is to give closures linear types, such that the client is forced to free them at the appropriate time.

Barry Kelly, reference counting is garbage collection, so your implementation was GC’d.

Parent p;
p = baz(-1.0);

would become something like

Parent __size__(sizeof(Child)) p; /*I’ll leave it to you to think of better syntax*/
p = baz(-1.0)

Something like this should then inform the compiler to reserve enough space on the stack for Child objects. You could probably call this ‘manual polymorphism’
This would probably require the compiler to track separately the interface and max size of every variable, so it would require quite a bit of rewriting in the typechecker. Also, it makes using inheritance more difficult and less modular than a fully general solution. You could end up with an error that ‘variable x cannot hold objects with size of DerivedClass’ when you change the definition of DerivedClass, forcing you to recompile all kinds of unrelated modules for which you may not have the source code (well, assuming Deca will actually be used in the wild).

Or an other way would be to have each activation record start with a table of pointers to variables, followed by those variables taking as much space as they need. The space needed by the variables would grow dynamically. But this would require indirection for all local variable accesses.

And as to the issue of state capture due to lexical scoping, I must admit that since my lambdas have copy semantics for closure construction, they Are Not True Lexical Closures in the case that one returns multiple closures over the same state. However, in that case I believe that an object (ie: instance of a class) will work well enough. It may not be The Right Thing sometimes, but it will work and it lets me have a somewhat functional language without GC (and therefore usable for low-level programming).

If you don’t use generics or templates, then you must use polymorphism. Whether you describe the lump of data being referred to as being POD or not, it will conceptually be a type, because in order for it to act as a lambda, it must be invokable and contain state; since the state may vary in size depending on the amount of captured data, the very minimum of type description – size – is necessary. (Size is also the only type known by assembler. Perhaps you would be more comfortable with that?)

Now as to the issue of garbage collection and memory management for the lambdas… that issue is solved through a bondage-and-discipline approach. I could write another whole post detailing how Deca alias types and anonymous variables work, but suffice to say that the language enforces a semantics which enables it to treat aliases as Plain Old Data for closure-variable-capture purposes without creating aliasing bugs. Think of uniqueness types, but done at runtime to avoid the need for a huge type-inference engine. Since aliases, the only reference type in the language, are Plain Old Data and everything that isn’t a reference type is either Plain Old Data or recursively defined in terms of aliases and Plain Old Data… everything is Plain Old Data for variable-capture purposes. Just copy it into a closure-object and go, basically. The closure-object then gets deleted manually later on. Like I said, the exact weird bondage-and-discipline I enforce on aliasing to make this work is worth its own post some other day.

And don’t nobody go telling me that this kind of thing is impossible or senseless.

I suppose I *could* simply outlaw returning functions from functions and require that they be passed as out arguments, but that ends up running into the same problem of either A) slicing or B) passing by reference, which requires allocating all my closure-objects on the heap (NOT a pleasant thing to do in a manual-allocation language, particularly for the perceived syntax and semantics of lambdas). There should be *some* way to return a covariantly-typed value on the stack!

If you feel like this won’t be a problem (maybe you only need so-called “downward funargs”), then it seems like you can just use a special stack discipline to handle variable-sized values: include the size of the function object somewhere in its representation, and respect this when pushing or popping the stack.