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:
Finally, I appreciate the feedback I've gotten on the model users document. Please remember the mantra of open source projects everywhere: "Patches welcome!"
