> In an applicative language, a continuation is a stack frame: it contains all
> parameters and all local variables of the function in question. The problem
> is that concatenative languages have neither parameters nor local variables.
> As far as I can tell, a continuation is merely "the rest of what would be
> executed in this function": in other words, it's a pointer to your current
> position in the current word. Four bytes, give or take.
Here's my understanding... a stack frame in an applicative language
is very similar to the data stack in a concatenative language (such as
FORTH or Joy), with this exception: an applicative stack frame will
contain an explicit return address pointer (i.e., the continuation
parameter) whereas a concatenative data stack typically would not
(instead relying on a separate "return stack" for this purpose).
Other than that, an applicative stack frame pretty much does the same
thing as a data stack in a concatenative language... both are used
to pass around parameters and local variables (although, in a concatenative
language there is not a distinction between parameters and local variables).
> Is this right, or do we also need to imitate applicative languages by making
> a copy of the entire data stack?
Hmm... I don't quite understand... What you said before sounds right...
A continuation parameter in the end takes the form of a return address
(four bytes, give or take), and is basically a pointer to the current
word (or rather, the next word).
But, then again, I've never dug into compilers that use continuation
parameters, so I could be wrong.
By the way, now seems like a good time to bring up the FORTH-like
technique of keeping the return stack separate from the data stack.
It seems like a good technique in many ways. Most importantly,
it permits one to call a subroutine seamlessly, without making copies
of things that are already on the stack, provided that they are in the
right place (otherwise, they might have to be swapped around).
This can result in speed savings, and in the case of deep recursion,
space savings as well.
However, I'm guessing that in a system that does inlining well,
the vast majority of time will be spent in an innermost procedure,
so that the overhead involving calls might not matter that much anyway.
- Brent Kerby ("iepos")