Representing continuations
Yesterday Jeremy Y. and I discussed the representation of continuations. We have a method in mind for doing it without actually embedding code in the continuations, but we could see a way out of passing environments around.
Naively, continuations do contain delayed expressions to be evaluated later on; for example if you apply a function, which is the result of an expression, to an complex expression argument, we need to delay the argument (on the continuation stack) while we evaluate the function. This is particularly comes up when you have curried functions, which is how Links' primitive functions are applied. So just evaluating 1 + (2 + 3) requires us to delay the evaluation of (2+3) while we find out what is + applied to 1. Perhaps some optimizations could be done which eliminate the problem in a lot of cases, but the problem still exists.
Our method for banishing the code is like defunctionalization, but I'm not sure whether it should be considered the same thing. Our idea is to take the tree (perhaps forest) which represents the program and assign an identifier to each node. One problem is in assigning those identifiers in a stable way, so that if I change an unrelated part of the program, the identifiers for the unchanged part remain the same; that should not be hard, just using good hash functions.