RE: A plea for a new old language

["Anton van Straaten" <address@hidden>]

Dan Sugalski wrote:
> What I'm considering is changing parrot's calling conventions such
> that it is *mandatory* that the caller pass in a continuation
> representing the caller's return location, rather than just pushing
> the return address onto the stack. Right now when you dispatch to a
...
> Going CPS makes calling easier. Rather than a half-dozen "push this
> thing" ops, a call, and then a bunch of "pop this thing" ops, it's
> just "make CPS thingie", call. And on the callee end there's no need
> to track the number of elements/frames pushed onto a stack so they
> get popped at the end, you just invoke the CPS thingie and the stacks
> are put back in the state they were when the call was made.

Sounds pretty plausible to me - it's hard to see why this would be a
stumbling block for VM developers.  You could easily write the above
description without using the terms "CPS" or "continuation" - just introduce
it as a convenient way to package up the return address and associated
state.  After that motivation, you could relate this to accepted terminology
("oh by the way, this is really a construct from the esoteric depths of that
shadowy field known as computer science and I'm really an agent for the dark
side, muhahaha...")

> The one issue that this does raise is "how do you affect the caller",
> since what if you *want* to affect the lexical chain or op function
> table of the caller? Though I suppose we could allow you to mess with
> the data stored in the CPS widget.

You're talking about something other than simply saving or discarding a
received continuation and invoking a different one?  Are you sure you want
to allow that?  It sounds like it could violate the integrity of the VM,
e.g. allowing bytecode that does bad things that can put the VM into an
illegal state.

Anton