|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Welcome to this week's Perl 6 Summary. And what better way could there be of spending the morning of your 36th birthday than by reading through a bunch of old messages in a couple of mailing lists and boiling them down into a summary?
Hmm... you have a point. Still, I'd just spend the day feeling slightly guilty if I did that. And I'd spend more than just the day feeling guilty if I did that, but thanks for the offer.
Continuing the thread of "So little was said we might as well get it over with and move onto the meat of the week", we'll start this week with the language list.
Piers Cawley wondered about doing multiple dispatch based on context and came up with a scheme which involved wrapping multimethods in a simple method that would 'reify' context so that it could be used as a multimethod argument. Luke Palmer came up with a better notation for handling class arguments to multimethods than Piers's suggestion...
In a transparent (and successful) attempt to generate some traffic on the language list, Jonathan Scott Duff wondered when the next Apocalypse was due. (If anyone's reading this who isn't up to speed on the Perl 6 design process, Apocalypses are Larry's design documents which describe the syntax and semantics of Perl 6. In theory they reflect the structure of Programming Perl, but the order may vary slightly).
Dan Sugalski popped up with an answer "Not for a while". The thing is, the next Apocalypse is objects, and judging by the amount of time it took Dan to get object internals finalized (hah!) over on perl6-internals, getting objects right in Perl 6 is going to take a time. Dan thought that Damian may well get Exegesis 7, formats, out sooner. (Apocalypse 7 boiled down to the following: "See Damian"). However, Damian is currently on holiday for the first time in too long, Dan hoped (and I agree) that Damian wouldn't answer for a few weeks.
There was general agreement that getting objects right deserved as much time as it needed. Luke Palmer dropped a few hints though (and made your summarizer happy by noting that 'the standard library will definitely be mutable at runtime'.
Alex Burr responded to a question about Macro arguments that Luke Palmer posed on the second of August (you have to love the dizzying pace of life on perl6-language). Alex suggested the partial evaluation might be handy but predicted that nobody will write a useful partial evaluator for Perl 6 as the language is 'simply too big'. The thread went on to discuss ways of getting at syntax trees from precompiled code and whether or not Alex had been serious in his prediction.
At the back end of last week, Leo Tötsch announced that he was looking into the AST (Abstract Syntax Tree) interface to Parrot by implementing parts of Yet Another Language (YAL). What's been done so far looks remarkably impressive, and Leo wondered whether to commit the changes. He noted that the work was currently totally standalone and could be distributed as a tar file instead.
Michal Wallace liked it, noting that he'd like to merge in all the pirate code generation stuff. James Michal DuPont suggested using the redland RDF API, and representing the syntax trees with RDF. Not being a fan of XML (Who is?) Leo was unconvinced, worrying that he wasn't keen on having an external library in such a central place in Parrot. James pointed out that RDF isn't necessarily XML, and that the redland API wasn't quite the same as the redland library.
Meanwhile, Leo put a YAL distribution up on his web page.
The "How to do serialization right" thread rumbled on. Threads continue to make things hard.
Amir Karger continued his investigation of what would be needed to get Parrot emulating the Z-machine. Later in the week he announced that he was about to start coding. Go Amir!
Everyone admits that languages/imcc is the wrong place for something as central to Parrot as IMCC. Leo wants to make a top-level imcc directory. Dan wants to move the current top-level C code to a core directory and move the IMCC stuff into that directory as well (without an imcc subdirectory). Quite what the Right Thing is hasn't yet been decided so IMCC remains in the wrong place. Robert Spier thought that we should wait 'til after the next Parrot release anyway.
Leo Tötsch noted that there appeared to be a few ops missing,
for instance there are
neg_i ops but
neg_p, he wondered if the 'missing' ops should be implemented or
simply worked around. Leon Brocard thought that implementing the
missing ops was the best course as it made it much easier to target
Parrot. He noted that we could always move the logic into the
assembler later if we decide to prune ops. Dan agreed. Leo set about
implementing, throwing up the occasional question about semantics.
As of Sunday 14th, Parrot is feature frozen in preparation for the next Parrot release. We're not sure whether this will be 0.1.0 or 0.0.11, but there's definitely a release coming soon. Steve Fink, who reserves the right to call it the "hairy tulip" release, nevertheless invited suggestions for release codenames.
Luke Palmer released the second revision of a patch implementing his proposed timely destruction scheme. He claimed that in his benchmarks he was seeing a 1000% speedup for lazy DOD runs, which can't be bad. Dan, Leo and Daniel Grunblatt all asked Luke for his benchmark programming, suggesting that it go in the examples/benchmarks directory. Dan also asked for Luke to have a go at writing a good torture test for the system. Assuming it survived the torture test, Dan thought we could commit the changes.
Vladimir Lipskiy posted a patch implementing a new variant of File Spec for the Parrot internals. (File Spec is a method of decoupling file paths from the gory details of particular operating system interpretations of what a file path looks like). It seems from the subsequent discussion that Vladimir and Michael Schwern have a fundamental disagreement about how a File Spec module should work.
Arthur Bergman, the Ponie Jockey asked if there was any documentation or code extant to help him figure out how to use PMCs in embedded mode. Apparently there isn't.
Dan is in the process of setting up the TPF Win32 tinderbox machine. However, he's not a windows person at all, so he solicited suggestions as to which particular build options would make useful tinderboxes. Melvin Smith offered up several suggestions of compilers etc.
In the Win32 Tinder thread, Dan told Melvin Smith (and by extension everyone else) that "it's your job, if you choose to accept it, to help make [Perl 6 Essentials] horribly out-of-date." Nicholas Clark wondered if there would be prizes for people who make the most paragraphs obsolete, and if anyone was counting. (It looks like Nicholas just volunteered). Dan reckoned that yes there would be a prize, the winner would get a mention in the forward of the next version, but he wasn't sure whether that would include a signed copy of the new version or a hand corrected copy of the old one... Nicholas voted for the hand corrected copy, and I second that suggestion.
www.ccl4.org -- Hand correction #1
I'm afraid I still don't have the info about the Perl Foundation's Parrot related grants. I'll nudge Gav and hopefully have something for you all next week.
I promise there will be new content at www.bofh.org.uk this week.
As ever, if you've appreciated this summary, please consider one or more of the following options:
Right, I'm off to enjoy the rest of my birthday. See you all next week.