The Perl 6 Summary for the week ending 2005-10-30
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.
This week in perl6-compiler
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ösing 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.
<http://planetsix.perl.org/>
Meanwhile, in perl6-internals
Discussion of the Parrot JSON serialization code span off into a
discussion of generalized serialization for Parrot data structures.
<http://xrl.us/ia4m>
Determining the number of return values expected
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.
<http://xrl.us/ia4n>
Rules for changing APIs
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.
<http://xrl.us/ia4o>
"check_progs" is not portable
François 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.
<http://xrl.us/ia4p>
The Configure System
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.
<http://xrl.us/ia4q>
Yet another C compiler
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.
<http://tack.sourceforge.net/>
<http://xrl.us/ia4r>
Deprecation warning
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.
<http://xrl.us/ia4s>
Compiling parrot with c++
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'.
<http://xrl.us/ia4t>
Documenting "new_pad"
Jerry 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.
<http://xrl.us/ia4u>
"All tests successful" considered harmful
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!
<http://xrl.us/ia4v>
Rejigging NCI to use the ffcall library
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.
<http://xrl.us/ia4w>
Meanwhile, in perl6-language
That darned class sigil
I just can't keep track... When Larry originally introduced a class
sigil, it was "¢". 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 ¢ because of difficulties typing the character on Asian
keyboards. The discussion was generally in favour of some kind of new
sigil though.
<http://xrl.us/ia4x>
Perl 6 Fears
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.
<http://xrl.us/ia4y>
<http://xrl.us/ia4z>
Ways to add behaviour
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 ops
Quickly, 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.
<http://xrl.us/ia42>
txt vs OO
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.
<http://xrl.us/ia43>
<http://xrl.us/ia44> -- Larry on cargo culting
"+$arg" changed to ":$arg"
Larry 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.
<http://xrl.us/ia45>
Roles vs. Classes
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.
<http://xrl.us/ia46>
Is there a way to generate an object without a new?
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.
<http://xrl.us/ia47>
Role Method Conflicts and Disambiguation
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.
<http://xrl.us/ia48>
<http://xrl.us/ia49>
Crossing lists
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.
<http://xrl.us/ia5a>
Acknowledgements, apologies and everything else
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.
Help Chip
<http://geeksunite.org/> -- Chip still needs help.
The usual coda
If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl.
<http://donate.perl-foundation.org/> -- The Perl Foundation
<http://dev.perl.org/perl6/> -- Perl 6 Development site
Check out my website, it's lovely.
<http://www.bofh.org.uk/>
Vaguely pretty photos by me can be found at:
<http://xrl.us/ia5b>
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
