| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Hmm... Thursday afternoon and I've only just started writing the summary... What happened to professionalism? What happened to rigid, albeit self-imposed deadlines?
Um... I've had a cold. The cats ate my homework.
It's weird isn't it? Activity on Pugs and the other Perl 6 compiler tools shows no signs of slowing (especially now conference season is over), but the volume of mail on the list continues to be tiny. Autrijus seems to be Erd\xF6sing round Europe and writing everything up on use.perl. I could give you a bunch of links to various other blogs and journals where various Perl 6 developers are writing up their work, but it's probably easiest just to point at the Planet Perl Six aggregator. It's good to see so much of this stuff becoming a little more visible.
Discussion of the Parrot JSON serialization code span off into a discussion of generalized serialization for Parrot data structures.
Leo and Jonathan Worthington discussed how to find out about the number and types of return values the caller expects. Jonathan ended up implementing an experimental op to kick around.
Leo talked about the Parrot policy for changing APIs. In general, it's a good idea not to have to change a public API, but in practice, it happens. As Leo said, the general rule is "You break it, you fix it", so the policy is that if any API changes break anything in the Parrot subversion tree, it's up to whoever changed the API either to fix it or to work with the the sub project's 'owner' to get it fixed. Projects that aren't in the tree will need to keep themselves up to date, but if you didn't document your changes well enough, expect to be fielding questions for a while after your changes.
check_progs is not portableFran\xE7ois Perrad pointed out that the check_progs subroutine used by Parrot's
config system doesn't work on windows. He suggested using the CPAN module
File::Which instead. This turned into a discussion about whether it would be
good to have a Bundle::Parrot set up on CPAN with all the CPAN modules needed
for Parrot to build, or if we should continue to bring those modules that
Parrot needs into the Parrot distribution so that, once you've downloaded the
Parrot tar file you won't need to scurry off to CPAN for various supporting
bits and pieces.
Understating the case somewhat, chromatic pointed out that the plugin system for configuration is grotty. Everyone agreed pretty much, but the question is whether to do anything about it since the current configuration is supposed to be a stopgap solution until we get the proposed miniparrot scheme up and running. Pretty big gap eh?
Hopefully this means we're going to get work started on the miniparrot approach. Or maybe someone will clean up the stopgap. Neither would be bad.
Leo pointed everyone at the Amsterdam Compiler Kit, which is the default compiler for Minix and wondered if anyone wanted to experiment with it to see if it could compile parrot.
Leo announced that the newsub operator is about to be removed. Check
docs/compiler_faq.pod for details of the Right Way of making subs. Patrick
had a few questions so he could track the changes in PGE. Leo answered them.
Nick Glencross wondered if it would be a good idea to make it so that Parrot couple be compiled by a compiler in C++ mode. The answer appeared to be 'yes'.
new_padJerry Gay asked about the use of the new_pad op, which appears to be both
undocumented and untested. Not good. He posted some apparently reasonable code
that fails. Matt Diephouse reduced it to a simpler failing case and Leo tracked
down the bug. None of which addresses the lack of documentation of course, but
it's a start.
Jerry Gay pointed out that "All tests successful" is only a useful message when you're confident that your test suite has good enough coverage. Jerry thinks parrot has too few tests. So he's started writing more and sending in patches. He noted that trying to write tests was a very good way of discovering areas of Parrot that aren't sufficiently (at all) specced. He called for others to join him in writing tests and picking off parrot's low hanging fruit. Go Jerry!
One of Jerry's issues was that you can't easily write tests in PIR. So chromatic pointed him at his Test::Builder ported to PIR and committed to getting Parrot::Test (or some useful subset of it) ported to make use of it. Go chromatic!
Nick Glencross wondered about rejigging NCI, the parrot Native Call Interface to use the ffcall library. In fact he went so far as to offer up a proof of concept implementation. Apparently the ffcall approach makes it much easier to write callbacks in PIR/PASM. Leo thought it sounded like a useful thing to do, but licensing issues (ffcall is under the GPL) meant that Parrot might have to stick with the current NCI interface.
I just can't keep track... When Larry originally introduced a class sigil, it
was \xA2. The discussion went off in several directions and, as I write this
and the next summary will probably say that the sigil is now longer \xA2 because
of difficulties typing the character on Asian keyboards. The discussion was
generally in favour of some kind of new sigil though.
Juerd announced that he's added a list of Perl 6 fears to the pugs distribution. The idea is to gather all the things that worry people about Perl 6 into one place and see what, if anything can be done to address them. People don't seem to like Unicode operators...
Slightly tangentially to this, Dan Sugalski blogged a couple of weeks ago about his successes and failures with Parrot. The comments are worth reading -- there's a fair few more or less well founded complaints about the way the Perl 6 project has been managed, many of which seem already to have been addressed. Certainly the design process is rather more visible now.
Ashley Winters has been thinking about all the different ways to add behaviour to classes in Perl 6. He came up with 7 and I think he missed a few...
A discussion between span off with Larry and Stevan talking about the hows of
whys of adding behaviour via .meta, which in turn morphed into a wider
discussion of how the Perl 6 metamodel's going to work. I find myself wondering
what we're going to run out of first, Unicode characters for new operators, or
terms for MetaModel concepts.
$_ defaulting for mutating opsQuickly, what does a line of code like:
given $subject { ++ }
do? Juerd thinks it should increment $_/$subject. The idea being that all
mutating operators should default to operating on $_ in the absence of any
other operand. Larry pointed out that, as you can already use . on any
postfix operator, it's already possible to write
given $subject { .++ }
He reckoned that changing the other operators in the way Juerd proposed would probably be a losing proposition. I'm not sure Juerd was convinced.
Michele Dondi replied to Stevan's assertion of a few weeks ago that "Perl 6's OO system has the potential to be to OO programming what Perl 5 etc, was to text processing". Michele thought that being known for OO might well be as much of a trap as being known for text processing was for Perl 5 (at least to the wider community of programmers who didn't look further than the headlines). In the ensuing discussion, Larry came up with the idea that the design of Perl 6 is aimed at making it possible to 'usefully cargo cult aspects of interest' without having to learn the whole damned language. When the OED adds the verb form of 'cargo cult' to its corpus, remember where you read that first. Even if you're not that interested in the rest of the thread, it's worth reading what Larry has to say on this.
groups.google.com -- Larry on cargo culting
+$arg changed to :$argLarry announced that one of the major changes in the latest version of Synopsis
6 was that named arguments are now marked with : and not +. The aspect of
this that had me punching the air and shouting "Yes!" was that it's now
possible to declare a parameter with both an external name and an internal
variable name (which is one of the aspects of Smalltalk style method selectors
that I really like). After a long post of thinking aloud, he went off to revise
the synopsis again. Discussion of the implications of using : ensued.
Rob Kinyon wondered if the only difference between a Role and a Class was that the Role was immutable. He reckoned that, if that was the case he'd rather use Roles all the time. Luke, chromatic and Larry thought he was wrong about this, pointing out that open/closed optimizations should be left to the class's clients not to the class itself. Essentially, if everything declares that it's not going to monkey with everything else after the compile phase is over, then perl can get on and optimize like an optimizing monkey based on the (good) assumption that all classes are closed for the duration of the program's execution.
Yiyi Hu doesn't want to have to type 'new', preferring instead to do
Class( b => 5). Luke liked the idea. Juerd didn't. Larry pointed that
making it work would have unpleasant syntactic ramifications.
Stevan had some questions about how method conflict resolution works with roles. He had a few simple, if pathological cases to demonstrate the issues. Various solutions were proposed, but I did find myself thinking of the old joke: "Doctor, it hurts when I do this."
"Well, don't do that then."
Ahem. The old ones are still the old ones. And the Old Ones are still the Old Ones, but I don't think we've yet added "Perl Six will awaken great Cthulhu from his long sleep beneath the island of R'Lyeh" to the Perl Six fears list.
Darren Duncan wants a 'simple way to combine 2 arrays where every element of
each array is combined with every element of the other arrays', he calls this
the cross operator. Luke pointed to several places where it, or something
like it had already been discussed, but I don't think it's something that's
made it in to the language.
groups.google.com[192.168.1.101]
Sorry it's late. I'll do better next time.
I'm still looking for work; perl or ruby programmer, photographer, tech writer, folk singer -- I'm multi talented. Let me know if you need any of 'em. Also, if anyone is interested in taking up sponsorship of the Summaries, please drop me a line, I'd be delighted to hear from you.
geeksunite.org -- Chip still needs help.
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl.
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
Check out my website, it's lovely.
Vaguely pretty photos by me can be found at: