Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chip (65)


Pumpking Emeritus for Perl 5.4 and Parrot

Journal of chip (65)

Thursday June 16, 2005
08:56 AM

Hackathon Days 4+5: Report

[ #25234 ]
Greetings from beautiful NiederOesterreich. Yes, this is Lower Austria, even though it's right up against Austria's northern border. I guess being close to the Alps gives the term "lower" a more concrete meaning.

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!"

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.