| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Right, hopefully things are back to normal(ish) after the disk crashes that rather spoilt the last summary. I've managed to fill in my mail archive too so this summary will cover the events of the last fortnight (that's two weeks for those whose version of English lacks this vital unit of time).
We start, as usual, with all the action in perl6-internals.
It's been a long time coming, but Dan returned from LL3 suitably refreshed by his dealings with academics ("You can [...] consider a a sub PMC as a frozen semi-stateless continuation") and set about unifying Parrot's call and return conventions. The strange thing is that everyone's been wanting this for months now, but that didn't mean there wasn't discussion.
Meanwhile Melvin Smith set about making this discussion moot (from the
point of view of someone targeting Parrot) by hiding the details
behind IMCC directives (which already happens admittedly, but
Melvin's in the process of renaming the .pcc_* directives to get
rid of the .pcc_ and (eventually) allowing for pluggable calling
conventions.
groups.google.com -- Dan's heads up
groups.google.com -- Changes, draft 1
groups.google.com[10.0.1.2] -- Dan puts his foot down
groups.google.com -- Melvin Makes it Moot
Stéphane Payrard bought a copy of "Virtual Machine Design and Implementation in C++" and reviewed it for perl6-internals. He didn't like it. Which is putting it mildly.
This led to the inevitable questions about finding good books on VM design. Stéphane quoted Leon Brocard's preemption of this question from London.pm: "No, there's surprisingly little out there on virtual machine design and development".
Melvin Smith continues to make PIR less like Assembly language and more like pseudo code. You can now write code like:
_foo() var = _foo() var = _foo(a, b) (var1, var2) = _foo(a, b)
and IMCC will do the Right Thing. Go Melvin.
Jeff Clites pointed out some issues with IMCC's behaviour when loading external libraries and wondered about definitive docs on the macro syntax (I think the current definitive docs may well be the source code). Leo Tötsch seemed to accept that there were issues with the current state of IMCC in this context, but implied that fixing it wasn't an immediate priority.
Melvin Smith proposed creating a parrot-compilers mailing list as a general purpose list for any and all language development targeting Parrot. He even went so far as to volunteer to maintain and distribute the FAQ.
The immediate response was positive, but Leo and others didn't really think the volume of traffic currently warranted it (which, I think, was part of Melvin's point, Parrot is reaching the point where it can just be used without necessarily needing to worry over much about its internals. I think Melvin is concerned that the technical level (and implicit Perlcentricity) of the current internals list is putting potential compiler developers off participating).
So, if you're reading this because you're interested in using Parrot as a target platform, but you don't subscribe to the internals list but would subscribe to a parrot-compilers list, could you let me, Melvin, or the list know? I've already committed to including any such list in my summaries (at least until traffic reaches the point where someone decides to do a dedicated summary). Let us know if you think it's a terrible idea too of course.
Michael Scott posted a review of Parrot documentation with pointers of where to find existing docs and a discussion of where people should be looking. Somewhat bizarrely, he failed to give the URL of the Parrot Wiki, his favoured source of documentation (favoured for the very good reason that it's excellent). However, you'll find the URL below.
www.vendian.org -- The very lovely and worthwhile parrot Wiki
Dan announced that he's checked in Leo's preliminary patch implementing freeze/thaw, commenting that it's likely to change dramatically internally and that the vtable/low-level API wasn't final, but that the op-level interface would be stable. Jeff Clites was initially concerned that the patch used things he was expecting to be able to use for his (in progress) ordered destruction patch. However, after some discussion, he and Leo seem to be confident that the two things can be unified.
Jürgen Bömmels has been doing a little warning patrol of parrot and finds that only a very few fixes to IMCC are required to get a warning-free compile and posted a patch with them in. Leo applied it immediately, reasoning that, whilst IMCC's under heavy development, there's no excuse for throwing compile warnings, and every time the perpetrators have to integrate such patches they'll become more likely to try not to generate the warnings in the first place.
Inspired by this, Jonathan Worthington posted a similar patch to eliminate warnings when building for win32, which Leo also applied.
Robin Redeker wondered which bits of Parrot and IMCC could be
considered stable enough to use in implementing a language. Leo opined
that existing syntax will not change much, most of the expected
changes relate to things like adding support for calling conventions
and simplifications like replacing .pcc_sub with .sub. Melvin
Smith pitched in with rather more detail about what was expected to
change and the kind of changes that could be expected in the
future. Reading this it's apparent that we've reached the point where
almost any conceivable extension to IMCC will be backward compatible
with earlier versions. Famous last words I know, but it is looking
that way.
=head Do Steve Fink's debugging for him
Steve Fink had a problem with some generated code throwing a segfault when it was run and, having hit the debugging wall himself, posted the code to the list and asked help. Leo tracked down the bug in Parrot and fixed it. However, that's not why this made the summary, what's interesting is the sample of code that the problem code was generated from. Here it is:
rule thing() {
<[a-z]>+
}
rule parens() {
{ print "entering parens\n"; }
\( [ <thing> | <parens> | \s ]* \)
{ print "leaving parens\n"; }
}
sub main() {
my $t = "()()(((blah blah () blah))(blah))";
my $t2 = $t _ ")";
print "ok 8\n" if $t2 !~ /^ <parens> $/;
}
Looks tantalizing doesn't it? Someone's now going to tell me that the code in question has been there forever, but I'm still tantalized.
Dan discovered that a make -j 4 dies quickly and horribly, which
seems to imply that there's a dependency or two missing from the nest
of twisty makefiles that make up the Parrot build system. He asked for
volunteers to fix things. There's been some work done on this, but no
definitive fix so far.
Dan threw a list of questions about IMCC out to the list as things that would really benefit from being documented. Sterling Hughes added a question or two, and Melvin Smith volunteered to get the answers written up real soon now.
Now that Parrot has the beginnings of freeze/thaw support, Melvin Smith restarted discussion of ensuring that Parrot's bytecode format is portable. He pointed at several issues that need resolving. Discussion continues.
Discussion of multi dispatch rolled on into the current summary
period. Luke Palmer pointed out that multi is no longer a
declarator but a modifier, allowing for fine-grained control of the
'scope' of a method/function/whatever. Larry pointed out that 'multi'
is orthogonal to scope, saying simply "I'm putting multiple names
into a spot that would ordinarily demand a unique name." and went on
to explain precisely what that implied.
groups.google.com -- Larry Clarifies
Rod Adams worried that all of the design of Perl 6 seems to come from Larry and Damian, with the language list being relegated to asking questions about how stuff works in more detail and in sniffing out tricky bits. Taken in combination with the real world's nasty habit of saddling Larry and Damian with health and financial problems, well, Rod worries, and wonders if there's anything that can be done to improve matters.
The redoubtable chromatic (who prefers it if I always render his name in all lower case, even at the beginning of sentences, hence his becoming redoubtable) gave the Standard Answer to such questions, pointing out that the reason things are going through Larry is because, well, Larry's bloody good at it. However, he did suggest that we're now at the point where we can probably start turning existing design docs into story cards and programmer tests for Perl 6, which should make implementation a good deal easier, and pointed to the Perl XP Training Wiki as a good place to look into how such tools are used to develop code.
xptrain.perl-cw.com -- The Perl XP Training Wiki
Luke Palmer doesn't like the repetition and ugliness inherent in code like:
my $is_ok = 1;
for 0..6 -> $t
{ if abs(@new[$t] = @new[$t+1]) > 3 { $is_ok = 0; last } }
if $is_ok { push @moves: [$i, $j] }
and wondered if there was a Perl6ish way of eliminating $is_ok. He
suggested something like:
for 0..6 -> $t
{ if abs(@new[$t] - @new [$t+1]) > 3 { last }}
FINISH
{ push @moves: [$i, $j] }
Simon Cozens made a plea to eschew adding syntax to the language when
it would be better to find a general mechanism. He wondered if a
better approach may be to have for return a status, by analogy with
Perl 6's if, which would allow one to write:
for 0..6 -> $t {
last if abs(@new[$t] - @new[$t+1] > 3;
} or push @moves: [$i, $j];
Which wasn't really well liked (I'm practicing my understatement here, okay?) However, Simon's point about distinguishing between Perl 6 the language and stuff that belongs in CP6AN (CPAN for Perl 6) was well made and taken.
The thread's almost unsummarizable, it went off in so many different
directions, and elicited some good stuff from Larry about the thinking
behind Perl 6, along with a horde of solutions to Luke's problem. Some
of 'em even work in Perl 5, at the expense of some seriously ugly
looking code. Piers Cawley wrapped one solution, based on a guard
clause approach, up in a higher order function, but fumbled the ball
on working out the macro syntax, which pulled the discussion in
another direction. Meanwhile other subthreads led to discussions of
generators, coroutines, Mathematica's Sow[] and Reap[] and
legitimate uses of goto.
And Larry emphasised that nested modifiers are still quite illegal in Standard Perl 6.
groups.google.com -- Larry on language design
s/// in string context should return the stringIn another of those deceptively 'pregnant' posts, Stéphane
Payrard proposed that s/// in string context should return the
string after substitution. Austin Hastings proposed something scary,
which led to Larry contemplating making
$x.s/foo/bar/.s/moo/goo/;
work somehow. (Which is actually less scary than Austin's original proposal). I think he rejected the idea for the time being though.
Piers Cawley suggested that it should return the substituted string,
with an appropriate boolean property set depending on whether any
substitutions were made. But then there issues of how you strip such
properties off if you want to use the standard boolean interpretations
of a string. Luke Palmer suggested the rather lovely but nothing
meta property.
I have the feeling that what's actually going to happen is that we'll
end up with a supplementary, non destructive form of s/// which
doesn't alter the original string, but returns a new string with the
substitutions made.
Sorry, we're a tad late again, sorry too to those of you reading this on the mailing lists, I've not got 'round to reimplementing the software to shorten the article URLs.
If you find these summaries useful or enjoyable you might like to show your appreciation by contributing money or time to the Perl Foundation and the Perl 6 effort. , or you could give me feedback directly at [email protected]'>p[email protected], or stop by at my website.
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
www.bofh.org.uk -- My website, "Just a Summary"