As I suspected, things quieted down for me quite a bit over the last two days
... they've gone from insane to merely busy. While Autrijus has been releasing Pugs, Leo and I have been designing things and considering priorities.
Candy first. Leo came up with a sane call/return convention for Parrot. After some discussion with Autrijus and me, Leo has now implemented a useful working subset of the final feature. The new call/return convention involves some new opcodes, does automatic type conversion and array flattening and ... well, read my update of PDD03 for yourself. (Yes! There are docs! A PDD even! And I've updated it! OMG! PDD! WTF?! If there's a fellow Parrot user near you, check to see if he needs resussitation...)
I've also been pondering priorities, and otherwise putting thought into the least hacker-like and yet most crucial Fearless Leader task: Pondering who Parrot should serve, and how. I'm not planning to live in Cloud City -- I'm a troglodyte hacker at heart -- but making design decisions where there is no clear right answer requires a usable utility metric. Otherwise you just end up floundering around and chasing cool things.
Actually, that's one class of user: the Magpie. ("Oooh! Shiny!") I've modelled the Parrot users I could think of in the Parrot Model Users document. Check it out. Who have I left out? Who matters the most? Don't worry about getting the right answer on those questions. There probably isn't one.
And boy have I learned a lot about continuations. Autrijus has been diving deeply into the literature on this for a while, and I've been picking his brain at every opportunity. (You can pick your friends, and you can pick their brains, but you can't pick your own brain. Or something like that.) The p6i discussion on the subject has been, well, mixed, not least because I've taken a few mail exchanges to figure out exactly what we need and want.
The short version of the situation with continuations is:
- Parrot will support full continuations, not just escape continuations. That is, continuations will not be limited to jumping up the current call stack.
- Parrot continuations will not require any new save and restore operations to work properly. One of the advantages of a virtual machine is that its state is always already saved. Right there in, you know, memory. Invoking a continuation is pretty much just switching your "current activation record" pointer.
- Parrot's register allocator will have to be changed to allow for the extra flows of control produced by continations. Essentially, no register assigned to a pseudo-register that is used across a function call boundary can be aliased to any other pseudo-register. This would have been a problem if not for the register expansion we already agreed to implement. Now it's no big deal.
- Finally, most PMC operations (except function call, of course) are guaranteed not to invoke full continuations. They can do the escpae continuation thing (i.e. throw an exception), but that's all. This is a requirement for two reasons: First, if those functions invoke Parrot code, they do so in a separate run loop, which makes the full continuation implementatin a real pain; but second, because we don't want to send the register allocator totally around the bend by making every PMC operation a boundary like function calls already are. This implies that if you want to invoke a continuation, you can't do it in your TiedArray::FETCH function. I don't think we'll get a lot of complaints about that.
And that's all the news from Herrnbaumgarten. Guten Nacht.