|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
What a surprise, a scant week after the last Perl 6 Summary of 2003, it's the first Perl 6 Summary of 2004. Will wonders never cease? Without further ado, we'll start with perl6-internals as usual.
Dan noted that a copying garbage collector doesn't play that well with threads so he proposed a twofold task to fix things.
The GC and memory allocation APIs need to be formalized and abstracted in order to allow for changing the GC mechanism when threads come into play.
Someone needs to implement a more traditional, non-moving GC as an alternative to the copying collector.
Stephane Peiry posted a set of patches to allow a parrot plugin for Mozilla. Not satisfied with this (but pretty darned impressed all the same) Sam Vilain noted that it would be nice if someone wrote an ECMAscript front-end to Parrot. Patches welcome Sam.
Harry Jackson couldn't get his build of parrot to finish running
make test. After a certain amount of thrashing about by the team,
Dan narrowed it down to issues with the mutant '2.96' version of GCC
that some versions of Red Hat used for a while. This is currently the
list's best guess as to the root of the problem, but it's not
absolutely certain. If it does turn out to be the compiler, the config
suite will have to be rejigged to detect and warn.
They're everywhere! And I despair of summarizing them. So I won't. Here's the root messages for anyone interested enough. Once things have died down and we know how threading is going to work in Parrot I'll summarize that.
Dan opened the floodgates and asked anyone who was serious about their particular Right Way To Do Threading to write things up as a proper proposal. He outlined the constraints that Parrot's threading will be working under and encouraged everyone to speak now or forever hold their peace.
groups.google.com[172.24.18.98] -- Dan says put up or shut up
groups.google.com[10.0.1.2] -- Dan offers up common terminology
Bernhard Schmalhofer found what looked like a bug in IMCC's macro support. This prompted Melvin Smith to expedite the removal of IMCC macro support as threatened some weeks ago. However, it turned out that that wasn't actually the seat of the bug. But if you like IMCC macros now is the time to make a very good case to Melvin, I doubt you'll convince him though; macros belong in a preprocessor.
David Cuny wondered if Parrot's objects were not at the point where it's possible to interface wxWindows to Parrot. So far he's been Warnocked.
Just try implementing it David.
Dan's a fan of core dumps (when appropriate) and wondered if there was a way of getting windows to either produce a core dump or attach a debugger to a crashed process. Vladimir Lipsky and Nigel Sandever gave good answers.
Dan forwarded the announcement that the Pie-thon Parrot Benchmark (which I've unilaterally decided to call the Piemark) code is ready. Let's make sure it's Guido not Dan who gets Pie eyed in Portland this year.
Luke Palmer wondered what work was needed to finish up Parrot's object system. Judging by Leo's response there are name mangling issues that need deciding on, and we're not quite sure who's supposed to be making the decision. Dan?
Whilst wearing his employee implementing a large project targetting Parrot hat, Dan has been using IMCC's debugging facilities. This led to a bunch of suggestions/decisions about how these could be improved.
Leo isn't enamoured of the current PDD16 design of callbacks in NCI, so he proposed a new design. Dan seemed to think that this proposal smacked of getting a little to sophisticated to early, arguing that the best thing to do was to flesh out what's there (and get it working) before using it as a base on which to build. This means that, once his work deadline is out of the way, we should be expecting some better examples in PDD16. And we'll be reminding Dan of this in a couple of weeks' time.
Nobody said anything. But that's boring, so on Friday I sent an email out to various denizens of the Perl 6 mailing lists asking them for their thoughts on where Perl 6 stands today and where they think it's going in the next 12 months. I'm pleased to say that, despite the ludicrously short notice, a decent number of people responded.
Everyone was remarkably consistent about where they think Perl 6 will be in the next year, they all expect to see a 'useful' alpha released and running on Parrot by the end of next year. Nat Torkington said that he didn't expect "any more unexpected delays -- I believe the doctors have run out of things to remove from Larry." and I think I am sure we all hope he's right, especially about the second part.
Leo Tötsch said that back when he answered the "Who's Who in Perl 6" questionnaire back in 2002, he'd said he thought Perl 6 would be out on 16 September 2004. He asked to increment the year of that prediction by at least one. Austin Hastings reckoned that we'd have a usable early version of Perl 6 sometime in Q2 or Q3, and expects the object apocalypse some time in Q1. However, he expected that there'd be fairly substantial exegesis drift from the original apocalypse to the 'real' design. Austin thinks that Perl 6's main 'cultural' impact will be grammars, arguing that in 10 years time 'getting coders to stop parsing characters, getting them instead to think, code, and word in terms of "sentences" or "paragraphs" will be considered a turning point.' Don't tell Austin this, but I remember Ward Cunningham saying something similar (but less emphatic) to me after Damian's Perl6::Rules presentation at OSCON 2003.
Allison Randal's in the slightly less bullish camp, arguing that it should be possible to produce a reasonably solid Perl 6 alpha in about 3 apocalypses time. She reckoned that we may see Apocalypses 12, 17 and 9 finished this year, and maybe a working prototype Perl 6 compiler. Allison's house mate, chromatic, reckoned that we were about 80% done now (I'm not sure if he was deliberately invoking the old saw that the first 80% takes 80% of the time, and the last 20% takes the other 80% of the time...). He predicted that:
Dan will win his bet with Guido, and that the Python.Net people will be so embarrassed by the piemark that they won't publish numbers.
Perl 6 won't quite be self-hosting, but it'll be usable for small apps.
NCI will continue to be much nicer than XS.
Apocalypse 12 will convince everyone that Roles are what object orientation should have had from the beginning.
Asked for pithy comments, chromatic gave good pith, noting that if he 'had a test case from everyone who asked "When'll it be done" and code to pass a test case from everyone who said "I'd like to help, but I don't know where to start"...' then he'd happily check them into the repository. He also said that anyone who 'wants to revive the Perl 6 Documentation project, start turning Apocalypses and Exegeses into story cards, and story cards into tests' would be his hero. And mine too. He didn't mention p6stories.kwiki.org so I'll do that instead.
Adam Turoff sounded a note of caution; he worries that Perl 6 'is Larry's Modula 2' but he doesn't think that matters because the real boon is Parrot (and Ponie) which has the potential to open the existing work on CPAN up to any language that targets Parrot (potentially making good work in other languages available to us Perlers too). He didn't think that Perl 6 will offer enough of an incentive for people to move to the new language from Perl 5. Indeed, he argued that the changes in syntax will put people off making the shift. We discussed this on AIM, personally I think Adam's wrong, and that Perl 6 will have enough good new stuff in it that people will bite the bullet of the new syntax (and the changes are reasonably simple after all) in order to get access to Perl 6's goodies. Adam certainly sees the change from Perl 5 to 6 as qualitatively different from the change from 4 to 5. He thinks people aren't going to switch quickly (especially if Ponie fulfils their needs) and he points out that it's going to be a few years before we've worked out the best practices for using all this new stuff.
Sadly, I didn't get any feedback from Larry before my deadline (if I do get something, rest assured it'll get space in next week's summary). I did get a lot from everyone's favourite evil genius though. Damian is alive, well and living in Australia. It seems that his recent silence on p6l may have something to do with his hopes 'to see Exegesis 7 published (along with a full Perl 5 implementation of the new formatting module) by late January.' In other Conway related news, he's attending linux.conf.au and will be attempting to describe the top 100 features of Perl 6 in 30 minutes. After that, he's 'set aside February through April to complete Perl6::Rules and a large test suite for Perl 6 regular expressions, under a small grant generously provided by The Perl Foundation'. Which can only be good news.
Me? I think Perl 6's design 'in the large' will be pretty much done once Apocalypse 12 and its corresponding Exegesis are finished. Of course, the devil is in the details, but I don't doubt that the hoped for existence of a working Perl6::Rules by the end of April is going to provide us with a great deal of the leverage we need to get a working Perl 6 alpha ready for OSCON with something rather more solid ready by the end of the year. Parrot continues to amaze and delight with its progress; Dan tells me that he's about ready to roll out a large parrot based application for his employers, so it's approaching the point where people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot.
Many thanks to those of you who took the time to answer my mail about Perl 6 in the coming year. Apologies to anyone who I may have offended by failing to ask them. If you've got strong opinions about where you think Perl 6 is going, let me know; I'll either make space for them next week make some space for discussion on my website.
If you find these summaries useful or enjoyable, show your appreciation by contributing to the Perl Foundation to help support the ongoing development of Perl. Money and time are both good. Also, I'm always pleased to get feedback at [email protected]'>p[email protected] and traffic at my website.
donate.perl-foundation.org -- The Perl Foundation
www.bofh.org.uk -- My website, Just a Summary