Notes
You can subscribe to an email version of this summary by sending an empty message to perl6-digest-subscribe@netthink.co.uk.
Please send corrections and additions to
perl6-thisweek-YYYYMM@simon-cozens.org, where
YYYYMM is the current year and month.
Perl "Assembly Language Standard"
A.C. Yardley submitted a proposal for documenting PDDs with the very-low-level operations of the Perl Virtual Machine itself. (This is a separate idea from the assembly language that will also be written.) A.C. will continue to work on it.
The "Perl Apprenticeship Program" Revisted
A.C. Yardley also revisited an old thread about a Perl Apprenticeship Program.
Nat Torkington:
Not to speak for Dan, but there's no code yet to review or learn from. I'd love to see someone set up a perl *5* apprentice program, and Mark-Jason Dominus has some ideas on how it might work. For perl6, though, we're not yet at a place where I think it makes sense. Right now there's so little defined in the way of implementation, that questions can be asked and answered on the mailing list.
Simon, however,
felt that the group was almost at the point where some coding could start, and
suggested that folks whisk through the
sv.c,
av.c, and
hv.c Perl 5 code (describing scalar, array, and hash functionalities,
respectively) to summarize what actually needs to be implemented.
Dave Mitchell and A.C. Yardley accepted the challenge.
Perl Virtual Registers
Dan Sugalski pushed for a register-based Virtual Machine, vice a stack-based machine, with little real dissention on that point. Dan, however, wanted typed and linked registers, but opinions were mixed on having typed registers, and generally opposed to having them linked.
Uri Guttman and Nick Ing-Simmons then took over the thread to banter about dealing with the stack/register window that will be necessary with threads and register overflows.
Here's a snippet from Uri's last response:
NI> That makes sense if (and only if) virtual machine registers are real NI> machine registers. If virtual machine registers are in memory then NI> accessing them "on the stack" is just as efficient (perhaps more so) NI> than at some other "special" location. And it avoids need for NI> memory-to-memory moves to push/pop them when we do "spill".no, the idea is the VM compiler keeps track of IL register use for the purpose of code generating N-tuple op codes and their register arguments. this is a pure IL design thing and has nothing to do with machine registers. at this level, register windows don't win IMO.
And a snippet from Nick's:
... My point is that UNLESS machine (real) machine registers are involved then all IL "Registers" are in memory. Given that they are in memory they should be grouped with and addressed-via-same-base-as other "memory" that a sub is accessing. (The sub will be accessing the stack (or its PAD if you like), and the op-stream for sure, and possibly a few hot globals.)The IL is going to be CISC-ish - so treat it like an x86 where you operate on things where-they-are (e.g. "on the stack")
add 4,BP[4]rather than RISC where you
ld BP[4],X add 4,X ST X,BP[4]If "registers" are really memory the extra "moves" of a RISC scheme are expensive.
Slices
Raul Miller threw out some ideas about slice syntax. There was some minor discussion centered around whether an array index in the new syntax is in scalar or list context by default.
This led to David Whipp proposing a new index context, to parallel the other contexts that Perl is aware of.
Slice References
Peter Scott bridged a posting from the perl beginners list, asking if it would be possible to allow non-copying slice references in Perl 6.
Damian Conway, of course, said, of course, "Of course":
@A = (1..10); # array
sub sliceref
{my($i,$o,$k)=(0,0,pop);$i+$o-$k->[$i]?++$o&&splice@_,$i,1:$i++while$i<@_;\@_}
my $ref = sliceref @A, [3..5,9]; # reference to slice
print "@A\n";
print "@$ref\n";
$ref->[1] = 99;
print "@A\n";
print "@$ref\n";
Properties Continued
The head-wrapping continued on the new properties feature of Perl 6. Although Damian gave some encouraging answers, he eventually posted:
I have already been discussing this with Larry and have privately sent him a complete proposal that, I believe, addresses all these issues. Let's wait and see what he makes of that proposal.
The Parrot Squawks
There has long been confusion between Perl (the community), Perl (the
language), and
perl (the program). This is only exacerbated on the inside
with various bits and pieces of Perl's (and
perl's) guts. Add the
complexity that Perl 6 is promising to add, and you've got a maze of twisty
little passages, all named "Perl."
Now, a while back, Larry countered a suggestion to use
Parrot as the project name for Perl 6 with a
list of codenames for various pieces, but it seems that Dan has been
slipping it in anyway. (The name
Parrot, of course, is from Simon's
tomfoolery earlier this year.) So it seems that at least the Perl 6 internals has a new moniker.
Until next week...
Bryan C. Warnock
