All the Perl that's Practical to Extract and Report
use Perl Log In
chip (65)
Post-OSCON Thread
Greetings, fellow primates!
I've just presented version two of "Parrot: Evolution" at OSCON 2006, and this is the URL I offered to the attendees. If you didn't see the talk, or you want to re-live that astonishing afternoon, please enjoy my presentation.
If you're interested in helping with Parrot, or if you want it to do something it doesn't do (which is also helpful), please post here, and we'll figure out the next step.
Onward & Upward: New Assignments
YAPC is, among other things, a wonderful opportunity to meet and talk face-to-face about things that concern us. This YAPC, one topic was how to get Parrot development on track to make it the VM we all believe it can be. One outcome of these discussions is a bit of a personnel shuffle, to wit:
I'm pleased to announce that Allison Randal is taking over as architect of Parrot, and I'm being promoted to pumpking.
Allison, of course, needs no introduction; as architect, she will flesh out the vision of a virtual machine for dynamic languages, that's been her primary interest from the beginning.
I, on the other hand, am very happy to be diving back into the code where
I've learned I'm the happiest. Writing specs and writing code are similar;
but when you're done with code, there's a "go" button, and lights flash and
wheels turn. It's the best toy set in the world.
Both Allison and I thank Leo Toetsch for his service as pumpking. He's done a yeoman's job getting parrot releases regular and stable. We're very pleased that Leo is staying on to continue improving parrot internals. Now that I'm going to carry the release cycle burden, he'll have more opportunity to respond to language implementors' issues, making Parrot better for all.
Onward & upward! Squawk!
YAPC 05 Hackathon Day 1: PDDs, PGE, and Testing
Links to many YAPC speaker slides are on the YAPC wiki.
And the hackathon begins...
I'm about to document the new dynamic_scope mechanism in a PDD. Meanwhile, Patrick Michaud, Will Coleda (coke) and Jerry Gay (particle) are here hacking on PGE, testing, and stuff.
In order to understand Parrot dynamic_scope, you should understand continuations. If you don't know about continuations, start by checking out the Wikipedia article on continuations and this introduction to continuations in Scheme. Extra credit for reading about Scheme's dymamic-wind.
Hackathon Days 4+5: Report
The last two days' activities included discussion of the detailed requirements of the lexical subsystem. So far I see no reason not to like most of Perl 5's model. Its one weakness was how it shoehorned names pulled in from outer subroutines into the same list with names that were locally declared. (Non-subroutine scopes scopes, i.e. nested blocks in a single subroutine, are relatively easy.)
In Perl 5, the lexical thing that doesn't work well looks like this: While compiling inner subs that reference outer lexicals, the compiler actually grabs a pointer to the outer value at compile time.[*] This works great if the outer scope is one-shot (e.g. the top level of a compilation unit, or a BEGIN block), but it totally doesn't work when a named sub contains another named sub. (Ever see the "variable won't stay shared" warning? No? Then you've never hit the resulting bug. It's there, though.)
([*] But when the sub is anonymous, it's treated as a closure, which captures the current value at runtime, rather than constructing an alias at compile time. Which is why Perl's closures work when they're anonymous, but not when they're named. But anyway.)
Perl 6 has some truly nasty multi-sub resolution semantics. I wouldn't want Parrot to handle it all, not that it could, but Parrot does need one adjustment to help: multi-dispatch can't be a one-shot operation. MMD lookup for Perl 6 will have to be a process of successive approximation, under the control of HLL logic. Some resolution can't be done until the sub parameters are evaluated (e.g. a where clause on parameter #2 that references value #1), but lazy parameters mean that Perl 6 is not allowed to evaluate them until it's absolutely necessary. So MMD resolution has to be tried first based on the compile-time-known types, but if that's not enough to know what to call, then the lazy parameters can be evaluated in order to get a more specific result. If this sounds incredibly fiendish, it is. And if that surprises you, then you've never listened to Larry, Allison, and Damian.
PIR, the high-level Parrot assembler, has some problems in clarity and implementation. Autrijus has been able to make PIR dump core fairly regularly, which is not acceptable. He's also brought up some confusing aspects of its parsing, which also are not acceptable. Some limited PIR language reform, along with armor-plating the implementation, seems appropriate at this point. For example:
- Type names should always be specified with a leading dot when they're known at compile time, with no exception for e.g. "new Integer".
- Opcode names should never be quoted and have parens in the style of named subroutines.
- Named subroutines must never be unquoted in the style of opcodes.
- Binding operations should be spelled ":=" rather than "="; "P1 = new Integer" followed by "P1 = 1" is just too visually confusing to live.
- The assignment syntax must be tightened up. "P1 = print" as a synonym for "print P1" is just incredibly evil; the use of "=" for opcodes must be limited to opcodes where the first operand really is an output result.
- And finally, PIR must never seg fault. Error handling is, if anything, more important in infrastructure like Parrot than in normal applications code.
Finally, I appreciate the feedback I've gotten on the model users document. Please remember the mantra of open source projects everywhere: "Patches welcome!"
Hackathon Days 2+3: Report
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
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.
Hackathon Day 1: Report
Yesterday was the first day of the post-APW hackathon, and it was quite a day
Variable-length register frames were an early topic. Register spillage is inevitable when you have a limited number of registers in your machine. However
PIR users will never notice the difference when register frames go all variable, since $P pseudo-registers were always infinite anyway. But things should get faster, and solving the problems of register allocation should be somewhat easier.
This is not a big deal to change, BTW. We even worked out how the JIT can handle it without loss of efficiency. Grabbing variable-sized hunks of memory is also basically a solved problem, what with, you know, strings and all.
(BTW, we have a new rule: PIR should be relatively stable, but it's OK to change pasm at any time, because humans should never write it. And fortunately it's not against the law to abuse silicon-based life forms.)
Calling conventions were the next topic. We'll have more specifics soon, but one thing Leo and I agree on is that the current convention is unnecessarily complex and an excessive burden on coders targeting Parrot. We're looking at abstracting it away from users so that all you have to write is "here are the arguments for the call I'm about to make" and "please put my incoming arguments in these registers".
Opcode count and policy was briefly discussed. The discussion was brief because Leo and I agree that the current opcode list is excessively broad. You don't make opcodes for all your IO and math and POSIX operations, for example. That's what libraries are for. So many opcodes will be migrating to standard libraries. Again, if you write PIR we can probably shield you from this change. PASM? You're on your own.
Lexical implementation was actually a topic before we got to Leo's
Well, today won't be nearly so high-powered, I'm sure. I'm focussing on documentation and the mailing list, and I'm going to get some details out of Leo on how we can implement these keen ideas, and how soon.
Share and enjoy!
Hackers, hackers everywhere...
PMC implementations are hard to read
/*
=item C<static PMC* undef(Interp* interpreter)>
Returns a C<PerlUndef> PMC.
=cut
*/
static PMC* undef(Interp* interpreter)
{
return pmc_new(interpreter, enum_class_PerlUndef);
}
Look at all the redundancy there. And consider all the vtable methods that have multiple implementations across many PMCs. Making programmers type the same thing over and over is just mean; it all the fun out of the coding. Something like this would be a lot better:
=method undef
=returns a C<PerlUndef> PMC.
{
return pmc_new(interpreter, enum_class_PerlUndef);
}
Everything else that's omitted here is, or should be, available elsewhere
If we want people to help us finish the PMCs, why not make their job a little more pleasant?
Perl6: I want to use this language
sub foo ($x: $i of Int where { $_ > 0 }, Foo +$j is required) {
... }
That kind of power gives a guy motivation to help make it happen.
Cheep Thrills
Dan Sugalski has done wonderful work as Parrot architect, and I really can't say that I'm replacing him so much as carrying on
Keeping a blog is not really my lifestyle; I'm more of a mail guy. But I've learned to include IRC, so why not yet another medium? It does seem that just about everybody these days has one of those new-fangled "web browsers". So here goes....
help them think they understand.
--Larry Wall
