Happy birthday to me! // Happy birthday to me! // Happy birthday, dear meeeee! // Happy birthday to me!
And, with a single breech of copyright, Piers was free. The production of this summary was delayed by my turning 35 on the 15th and then spending the Monday train journey reading one of my birthday presents (Dead Air by Iain Banks, it's jolly good) instead of writing a summary. So this morning, I left the book at home.
So, what's been going on with Perl 6. We'll start, as usual with perl6-internals.
The week before, Dan had asked for some suggestions as to what should be the priorities for the 0.0.9 release of Parrot. One of Nicholas Clark's goals from last week was the 'Careful elimination of all compiler warnings, particularly on non x86 platforms, and for builds with nondefault INTVAL size,' and discussions of how to go about doing this (and indeed some doing) carried on into this week. There was also some discussion about whether IMCC and the Perl 6 compiler should be built by default. On the one hand, it would mean that the tinderboxes were testing those important subsystems, on the other hand, it was thought that there were some people who wouldn't be interested in testing those things. Consensus seemed to be that we should just build and test them anyway.
Jürgen Bömmels and Piers Cawley continued their discussion
of how to go about implementing a scheme interpreter, and
particular. Piers made noises about a proof of concept implementation
of Scheme that he'd made using Perl objects, but didn't show
code. (And, I can exclusively reveal, will not be showing the
original) code owing to badness with backups and lackadaisical use of
CVS). Jürgen, who had actually made the effort of writing some
code, listened politely and agreed that Piers' suggestions looked like
they might be a way forward. Jürgen went away and implemented a
first cut at
Clinton A Pierce restarted this thread and discussed what he'd like to
see (apart from a pony) from Parrot's equivalent of Perl 5's
pack. Clint wondered whether Parrot
pack should use a template,
or if it should be implemented as a horde of smaller ops, each
handling a different conversion, so that a single, Perl level call to
pack would become lots of op calls at the parrot level. Clint also
drools at the thought of doing
sprintf at the parrot level. Aaron
Sherman agreed with most (all?) of Clint's proposals, and also wants a
pony. (Who doesn't?). Peter Gibbs went so far as to offer a patch
which implemented a subset of pack functionality, and was
applauded. Graham Barr wondered if pack should also allow for packing
to 'native' types, which wouldn't have to worry about
endian issues. Peter thought that would be a good idea. Nicholas
Clark pointed out that extending the code to cope with unsigned
integers would be a good idea, too.
Jürgen Bömmels asked a pile of questions about the implementation of lexical variables and how one could use them to make a closure. Jonathan Sillito provided a mixture of answers and guesses. It seems that we're waiting on Dan to firm up some things about lexicals.
Leopold Toetsch has been working on getting IMCC to generate parrot
bytecode directly rather than going through a stage of generating an
.pasm file, and had been having some problems with
'writing out the .pbc, especially Const_Table, type PFC_KEY /
PARROT_ARG_SC'. Two hours later, he announced that he had all the perl6
tests running successfully within IMCC, but only if GC was turned off
(there are problems with the longer running tests when GC is turned
on). Things get progressively worse as first JIT, and then
Predereferencing are turned on.
Dan wondered what the GC bug could be. Leo wasn't sure but posted some possible pointers. Peter Gibbs thought that at least one of the bugs was in continuation.pmc and posted a patch that fixed one of the problems when running under parrot. Meanwhile, Leo tracked down the bug to a bit of code that he'd appropriated from debug.c, so he fixed his IMCC and sent in a patch to fix debug.c as well. Applying both patches meant that the tests all passed under both IMCC and parrot.
Dan applied both patches.
Leo later fixed his problem with writing out a .pbc file directly from IMCC, and offered a patch to packout.c which he described as ugly, but working.
I think Mr Toetsch is going go get my 'kudos' award for this week as he later patched things to make the 'predereferenced' run mode work again (all perl6 tests pass when run with -P). By the way, there appears to be no reference to 'predereferenced' in the glossary.
http://groups.google.com/groups -- Problem
http://groups.google.com/groups -- Qualified success
Aaron Sherman and others have been torture testing the Perl 6
compiler. The most comprehensive test is the Builtins.p6m file (now
split into several smaller files) that provides prototypes (and a
smaller number of implementations) for Perl 5's built-in functions (we
don't know what Perl 6's builtins will be, so Perl 5 is a good
start). Sadly, right now, the Perl6 compiler can't cope with all the
builtins, so there's been a game of working out which is broken, the
parser or the code. Aaron has posted many short scripts highlighting
problems he's found. My particular 'favorite' is
my $x = 1; $x =
+x, sending the compiler off into an infinite recursion. Sean O'Rourke
has added these issues to his queue.
Leopold Toetsch posted a proposal for altering the build system to get rid of some rather over the top duplication of (generated) code. Nicholas Clark liked the idea, but I don't believe the patch got applied -- yet.
Leo also suggested moving the op_info_table out into a separate file which could be shared by the various core_ops*.c files.
Leon Brocard (yay! Still batting 100 percent on this one ...) has been having problems building IMCC under Mac OS X. The individual .c files all compile, but bad things happen at link time. Leo, Kevin Falcone and Andy Dougherty all pitched in and, after a flurry of patches, IMCC is now building and working correctly under Mac OS X.
There have been problems building Parrot on some of the tinderbox systems, and many boxes are not green. Andy Dougherty had some thoughts on this, and on how to improve things. Andy's view is that so many of the tinderboxes are broken, it's hard to tell whether your new patch is making things better or worse, especially when the rebuilds can take several hours in some cases. Andy hopes that, once the majority of boxes are green most of the time, people will take more notice when one or another turns orange or red. In another thread, Andy offered a patch that had been a showstopper for some architectures, which would dump core during config's alignment detection tests.
Leopold Toetsch wondered about the handling of compound keys in PerlHash objects. Dan confirmed that Leo's intuition about this was right, which was good, because Leo had a patch ready, but he still wondered about a some additional vtable methods. So he made some more proposals about how to deal with that case. Dan again agreed with Leo's analysis, and Leo came up with another patch. Steve Fink apologized for not having done this already, but his 'tuit shipment was confiscated due to heightened airport security.' Steve also neatly summarized the conclusions reached last time this came up.
Meanwhile, Graham Barr wondered where any type checking would happen. Leo thought it was implicit on lookup and showed code. So did Dan, but Ken Fox is still unsure.
http://rt.perl.org/rt2/Ticket/Display.html -- Leo's patch
The week before, Erik Steven Harrison had wondered what counted as a
runtime property, apart from
false. This week, Damian
popped up with a list of 10 off the top of his head.
return 255 but
$name = "Damian" but We_better_call_ya("Bruce") anyone?
Aaron Sherman's efforts at producing an initial builtins list for Perl 6 got discussed on the language list as well. Chuck Kulchar had wondered how well, if at all, they worked with the current perl6 compiler (they don't... yet), and why they were written in Perl. Aaron Sherman posted his reasons (maintainability, maintainability and maintainability). Nicholas Clark argued that Parrot code wasn't necessarily hard to maintain, and also made the case for implementing some functionality in C. Aaron thought that, eventually, they're be a mix of different implementation languages, with many of the 'munge args, call equivalent library function' type functions moved out into libraries anyway.
Discussions of the Perl 6 rules system rolled on. David Helgason had
worries about hypothetical variables but keys in a hash and should not
therefore have sigils in their names at all. Damian pointed out that
all Perl 6 variables were just keys in a hash. David wondered
about the difference between binding a value to a variable in a
containing scope and just binding to an entry in the match object
(Damian and Allison apparently have a really neat idea for this, but
it's not yet had the Larry stamp of approval). David's last worry was
$0 was a rather cryptic name for the match object and
shouldn't it have a meaningful name like
$MATCH (Damian thought
that squashing a cryptic name in favor of an arbitrary one wasn't
necessarily a win.
Jonathan Scott Duff had wondered (in off list mail to Damian, but
Damian answered in public) how he could tell
$$ only to
match just after and before his platform specific newline
sequence. Damian thought that suggested rolling ones own
<eol> rules. Jonathan had also wondered about some of the
the binding semantics of nested rules. Damian's answer gave him an
appropriate 'ah! yes!' moment.
Aaron Sherman had another question about rules and kicked off the 'Throwing lexicals' (Weren't they a band?) by wondering 'How do rules create hypotheticals?' Everyone passed up the chance to do a 'Well, a mummy rule, and a daddy rule, who are very much in love...' joke, leaving it to the summary writer.
I confess, I'm not sure I understand Aaron's concern (about what to do when you assign to a hypothetical that doesn't exist in a containing scope. I thought you just bound to an appropriately named key in the current match object), which makes things a tad tricky, but Luke Palmer seemed to understand and wondered if there would be some way of declaring that a given hypothetical wouldn't infect its containing scope(s). Damian popped up again, promising that, once Larry had made a decision, he would be unveiling one of the solutions that he and Allison have cooked up.
Piers Cawley wondered about blocks, statements and when they need
terminating semicolons, and kicked off a long thread. To be honest,
I'm not sure it really went anywhere, but we covered a lot of
ground. The confusion arises, I think, because the design of Perl6 has
moved (rather substantially in places) from the design described in
some of the earlier apocalypses and exegeses. Questions like 'is
when a statement, or just a clever function?', 'has Larry changed
his mind about no special cases for blocks?' and others would appear
to be standing in need of some definitive answers. These will, of
course be forthcoming, if only in Perl6's final grammar, but we're an
Aaron Sherman had a few thoughts about XS (well, whatever is going to
replace it in Perl 6 and Parrot anyway) which he shared with the
list. Essentially his proposals covered ways in which modules that are
partially implemented in other languages could be cleanly declared and
prototyped using Perl syntax rather than the current method involving
XS, which looks like no other language on ghod's green earth. Brent
Dax proposed a slightly different syntax, using a
sub foo is returns(...)? Don't you love grammar?). The thread got
rather long as Brent and Aaron discussed things back and forth, with
Nicholas Clark interjecting at one point to draw the participants
attention to the fact that they seemed to be on the verge of
reinventing Inline::C. Tim Bunch suggested that we 'should be thinking
about the forward declaration syntax and semantics for using existing
libraries at this stage. [He suspects] that it'll then become clear
how to add extra code in a simple and natural way.'
Tim also pitched in with a long quote from Larry about his goals for the Perl 6 extension mechanism.
David Whipp wondered whether we shouldn't actually be thinking about
Parrot's XS replacement rather than Perl 6's. Aaron thought not,
because even when parrot's extension model was fully specced out, we
still need to worry about how that interacts with Perl at a language
level. Dan Sugalski disagreed with Aaron, pointing out that Perl 6 XS
isn't due to be dealt with until Apocalypse 21. Aaron wondered whether
this really meant we'd be waiting for '16 more Apocalypses before
we write code that allows
chdir() to call the C library function?'
Dan thought Aaron was worrying unduly and pointed out that
is, or will be, a Parrot opcode. Aaron responded to this by stepping
back and defining some useful terms and stated his current position in
those terms. And then the week ended.
This one could run and run. Tune in next week for the exciting continuation. (Ooh, we haven't done continuations recently have we?)
In a subthread of the 'blocks and semicolons' thread, Aaron Sherman wondered about passing arguments. Aaron listed five different forms and wondered about how one would mix up the different styles. Luke Palmer and Brent Dax both wondered what made one of his special cases a special case. Again, it looks like the whole area of prototypes could use some cleaning up (but then we're currently working on clues from other design documents; hopefully the upcoming Apocalypse 6 will clear up many of these issues).
Steve Fink committed his IntList patch, and Josef Höök queried the creation of an intlist.c file in the Parrot core, as his matrix patch had been rejected for doing something similar. Nobody has responded to this yet.
Ramesh Ananthakrishnan wondered whether compiling C down to Parrot would be a useful thing to do, as a way of magically porting useful stuff that was already written in C. Aaron Sherman thought that it wouldn't be useful as a 'magic porting' tool, as that would be better done by linking to existing C libraries, and that for small fragments, a manual conversion would probably be better anyway.
Ramesh (or should that be Ananthakrishnan) also wondered whether it is possible to write networking code in Parrot. Answer: Not yet, but a Sockets extension is probably get written at some point.
Andy Dougherty patched the build's link order to take traditional, order dependent, linkers into account.
Jerome Quelin fixed Befunge (though, with a language like that, how
anyone could tell it's broken is a mystery) to use the new
Dan Sugalski turned 35 on the 12th. I turned 35 on the 15th. Did I miss anyone else's birthday?
Leopold Toetsch patched
Parrot_vsprintf_s and after prompting
supplied a test that failed without the patch in place. (Remember
boys and girls, if you're offering a patch that fixes a bug, make sure
you also supply a test that shows up the bug.)
Jeff Forr wanted to declare next (this) week to be a week of bug hunting, but Nicholas Clark pointed out that this clashed with YAPC::Europe and maybe it was better to make the week after a bug hunt. Jeff agreed.
Also going on last week was a Perl 6 mini conference, held in Zurich. Larry, Damian, Dan, Allison and Hugo all gathered to sit around a table and thrash out some more of the Perl 6 design. I assume that whiteboards were also available. As well as doing design work, there was a mini conference, complete with talks from all of the above, and due to time and money commitments I couldn't make it. However, Paul Johnson could, and he wrote me a report, which I present here pretty much unedited.
Last week, Perl 6 moved to Zürich. The bulk of the Perl 6 design team was here as guests of ETH, and spent the week, er, designing Perl 6 I suppose. But maybe they were out exploring Zürich and its environs. If they were, who can blame them? If they weren't, well they'll just have to came back another time :-)
On Thursday and Friday they also managed to fit in a Mini::Conference on Perl 6. In attendance were Larry Wall, with his wife, Gloria, Damian Conway, Dan Sugalski, Allison Randall and Hugo van der Sanden.
We were treated to two days of talks and discussion about Perl 6. Larry Wall gave the keynote speech to start the conference. As always, Larry's talk was interesting and entertaining. The scheduled topic was "Studies in the Ballistic Arts", however, Larry said that this title was prepared before the talk itself, and the talk, along with the title, morphed into one about the Science of Perl. This will be heard again at YAPC::E in a few days, and so I won't spoil it by attempting to summarise it here.
Next up was Damian Conway, who gave his presentation entitled "Introduction to Perl 6", covering the first five Apocalypses. Damian has managed to acquire quite a reputation within the Perl community, and Larry promised that Damian would be more entertaining than he. That was quite a promise, but I don't think anyone was disappointed. Damian in turn promised that Dan, speaking next, would be more entertaining than he. I think Dan was probably too busy to notice, checking in some patches or redoing the GC or something.
Damian noted that the audience was probably more sympathetic than most he gave the presentation to, given that they had come to a two day conference devoted to Perl 6. There were nonetheless a number of people who were worried about the move to Perl 6, and one who was still worried about moving to Perl 5! I think that most of Damian's jokes flew high over the heads of most people, but I appreciated them at least. I suppose that XXXX (4x) hasn't made it to Switzerland. And maybe Crocodile Dundee wasn't such a big hit. Even Switzerland's joining of the UN two days earlier seemed to go unnoticed, although it is UNO here. I think there were a few Java programmers in the audience too, since when Damian mentioned about Java having a HelloWorld library about half the audience laughed and half seemed a little concerned that they hadn't heard of it before. And the suggestion that Archbishop Tutu might not like being interpolated was entirely missed. (Should we interpolate $to too?) Still, had the jokes been in German, they'd have flown right past me instead. And I trust Damian's German accent will stay in place should he have occasion to talk about B&D languages in Munich.
Unsurprisingly, Dan spoke about "The Parrot Virtual Machine". Dan actually gave two presentations back to back. The first was an overview of Parrot, and the second was a more detailed look at parts of it. This was a very interesting look at the fast moving world of perl6-internals and seemed to be well received by a knowledgeable audience.
The second day started with a presentation by Allison Randall entitled "Linguistic Basis of Perl 6". Every so often, in perl6-language in particular, some discussion about linguistics crops up, often referring to tagmemics. Allison explained to us what a tagmeme is, and how it relates to the design of Perl 6. I won't pretend to understand it all, but apparently tagmemics is the Swiss Army Knife of linguistics, a tagmeme is a unit in context, tagmemes are fractal, and both "etic" and "emic" are real words, protestations of my spell checker to the contrary notwithstanding. I understand that Allison gave this talk at TPC and will also give it at YAPC::E, so soon we'll all understand tagmemic matrices and be perfectly happy to get dropped off into some uncharted jungle.
Following Allison's presentation there were questions about some minor syntactic issues such as why the switch statement used "given" and "when" instead of "switch" and "case". The explanation of how nicely it read in English was countered with arguments that that wouldn't benefit the German speakers so much and that "switch" and "case" were probably already familiar to programmers. Damian suggested that maybe a German Perl grammar would be in order, to which the inevitable response was that a Swiss German grammar was really required, but which dialect would it be in? Damian showed how easy it would be to derive your own Perl grammar and change keywords if you didn't like them. This was also useful to the chap who wanted elsif spelt correctly.
Damian's second presentation was "Programming in Perl 6" in which he took a number of real Perl 5 programs written and regularly used by prominent members of the Perl community, and he changed them into Perl 6. He did this twice, first to produce a minimal delta change and second to produce idiomatic Perl 6, at least insofar as Perl 6 has managed to acquire idioms. Both of Damian's presentations were punctuated with questions to Larry, asking if what Damian had just presented was true this week too. In some cases the language design seemed to be taking place before our eyes.
This presentation seemed to allay a lot of fears and everyone seemed quite happy with Perl 6 to the extent that Damian finished half an hour early. The option was a long lunch or Damian offered to give his Lingua::Romana::Perligata presentation. I don't think there was ever any doubt, but when Larry mentioned that he had never heard that talk it was decided. The talk is normally two hours long, but Damian managed to squeeze it into 45 minutes. I think this was probably aided in part by most people simultaneously missing the jokes and being comfortable with a language which requires the matching of number, case and gender. I suspect this is the opposite from most native English speaking audiences.
Finally Hugo was here representing the face of sanity. He told us of his plans for Perl 5.10. These included making perl clean, small and fast. To this end he intends to rewrite parts of the regular expression engine, to oversee the creation of a scheme whereby there are multiple blessed perl installations, and to claw back some of the speed that has been lost since version 5 was released. In short, to ensure that making Perl 6 better, faster and stronger than Perl 5 is as difficult as possible.
Last on the agenda was a question and answer session with the entire team. This was especially interesting, in part I think because there was not an enormous number of questions. This allowed the answers to be complete, to the point of verging on rambling. That's not a bad thing, because it let us get past the superficial answers and into more philosophical areas. Dan told us why Parrot was called Parrot. Larry told us why Perl was called Perl, what it stood for and when, and why it was perfect for search engines even before there were search engines. Dan told us not to get worried about everything, after all, it's only ones and zeros. Damian and Dan alluded to interesting things they could tell us, but then they would have to shoot us. Larry speculated on whether placing a time bomb in the perl interpreter would help us find out who is using Perl and for what. Larry and Damian told us some scary things that people do with Perl and Larry told us he flew over here in one of them. Larry also told us the secret of leadership (which is at least 2000 years old), and talked about how well his goal for the community's rewrite of the community is working. And there was a bunch of other stuff that I was far too busy enjoying to make notes about.
All in all, it was a thoroughly enjoyable and informative couple of days. Many thanks to ETH Zürich and in particular to David Schweikert for organising the event. Attendance was about 90, and profits, which look to be around CHF 4000 or so go the the Perl Foundation. Next stop: Münich.
You lucky people, last week you got Dan, this week it's Damian. Next week, the World! Bwah hah hah ha! Ahem. Without further ado:
- I help Larry with the design of the language syntax and semantics.
- I write the Exegeses (which explicate Larry's Apocalyptic designs).
- I create Perl 5 modules to prototype and demonstrate Perl 6 features.
- I roam the worlds -- both real and virtual -- explaining Perl
- Where are you coming from?
- Two years of electrical engineering degree, four years of computer science degree, six years of Ph.D research, eight years of designing programming languages, two decades of teaching programming, an abiding interest in human-computer interaction, a deep scepticism of formal/theoretical solutions to practical problems, an abiding belief that computers and languages were meant to serve humans not vice-versa, and the overriding axiom that simpler is better (or, at least, simpler).
- When do you think Perl 6 will be released?
- By Christmas.
- Why are you doing this?
- I'd been doing language design for the better part of a decade before I started using Perl. So when the opportunity arose to work on my favourite language and collaborate with such an extraordinarily talented team of people, how could I possibly resist?
- You have 17 syllables. Describe yourself.
Out of the torrent an excited voice describes the passing wonders.
- Do you have anything to declare?
- You're kidding, right? How many hours do you have?
You may have noticed that I'm a little late mailing out the summary this week (though if you read this at www.perl.com you're probably wondering what I'm on about). Things have been hectic, and I really can't type or think fast enough. Normal service will hopefully be resumed this week.
Thanks are due to Damian for making the time to answer the questionnaire, even if he did cheat on the 'five words' question. Thanks are also due to everyone who has taken the time to send me answers over the weeks, apologies for not thanking you immediately. As usual, if you're involved on either of the main Perl 6 development lists, please consider answering the questions and sending your answers to mailto:5Ws@bofh.org.uk. I'm running low on answers, and I'd really like to see responses from (among others) Leopold Toetsch, Steve Fink, Brent Dax, and Jeff Goff. I don't care if you've already answered Bryan Warnock's questions, it's a different summary now.
Thanks too to the crack team of proofreaders from the rhizomatic.net irc server who will hopefully have whipped my grammar into shape by the time I think 'I really should get my finger out and post this.'
As usual, if you think that this summary has value, please consider sending money to the Perl Foundation http://donate.perl-foundation.org and help to support the ongoing development of Perl. The O'Reilly Network will, as usual, be paying my publication fee for this article directly to the Perl Foundation. If you didn't like the summary, then write your own; different viewpoints are always welcome.
If you want to reward me directly, well, iBooks are always nice (but I'd be so embarrassed if I received one), but so is feedback. Let me know what you think.