| 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 back to the weekly Perl 6 Summary, which I'm hoping to keep on a weekly cycle for the foreseeable future.
It's been a relatively low volume week this week, I'm assuming that Thanksgiving had something to do with it (I hope those of you who celebrate it had a jolly good extended weekend), and for the first time in ages perl6-language saw almost as much traffic as perl6-internals. We're still going to start with perl6-internals though.
Last week Dan put up a list of questions about IMCC, intending it as a bit of grit. This week Melvin Smith added a couple of layers of nacre by checking in an initial IMCC FAQ (you'll find it at imcc/docs/imcfaq.pod in your parrot directory if you're following with CVS). After an initial flurry of work on adding to the FAQ, the discussion seems to have drifted off into discussions of bike shed pigmentation. Yes, the FAQ may need to be split eventually, but splitting an FAQ into sub documents is trivial compared to actually answering the questions. Ahem. Editorial ends.
www.parrotcode.org -- The FAQ
Vladimir Lipsky had a few questions about how the Parrot IO subsystem (PIO) handles error conditions. This sparked a discussion of whether the various PIO functions should make some assertions up front about their arguments. Consensus said "yes", they help with debugging, and the performance 'hit' is minuscule.
Discussion of the details of object serialization continued this week. Judging by the amount of clarification traffic that's been going on in this thread (and others), I find myself wondering if the time has come for some generous benefactor to sponsor the principals to get together in a conference room with copious whiteboard acreage. Sponsors welcome.
Consider a system of test machines, all of them happily running in unattended mode, constantly checking out the latest version of parrot, compiling everything, running the tests and reporting the results to some central webserver that displays a status report for all to see. It's not just a good idea, it's the Parrot tinderbox.
Now, consider an operating system that takes it upon itself to throw up a modal dialog box when a program segfaults.
The two don't sit well together do they? Which is why Dan has committed a patch to disable the "Your program has crashed, want to send a report to Microsoft?" box that pops up on Win32 when Parrot segfaults. Still, at least it can be disabled.
Dan asked for opinions on whether the (non tinderbox) default should be to put up a dialog box or not. And it appears that, if you disable the dialog box, there's no other notification (apart from the failed test, obviously) that there was a segfault. I am sure I'm not alone in boggling at this, but it looks like the default will be to display the dialog.
Allison Randal sent in a patch to update the Perl 6 compiler to use
the right operators (^+ becomes »t;+«t;, ~~
(meant xor) becomes ^^, making way for =~ to become
~~). She's still working on other tweaks to get the semantics of
what's already been implemented right, and claims to be sufficiently
annoyed by the failing regex tests that she might have to go and make
them work to remove the annoyance. Which would be good. (I'm afraid
that the tantalizing code I mentioned last week has actually been
there for ages, as I feared it had). That capital fellow, chromatic
applied the patch.
Dan got around to specifying some details about string formatting and
transformation. Essentially there will be various case changing
transformations and a couple of different formatting approaches, one
sprintf like and another more like traditional COBOL style
formatting. Dan's not sure yet whether these formatters will get ops
or simply be implemented in the standard library.
groups.google.com[10.0.1.3]
Someone calling itself ibotty wondered if there would be a default PMC method that gets automagically called whenever a method call isn't found. To which the answer is "Yes, when it's done".
Cory Spencer wanted to know if there was a PASM way of finding whether
two PMCs share the same memory address. "Not yet", said Leo
Tötsch, "but there are entries in the vtable to do it". This
sparked a discussion of the meaning of 'equal'. It was suggested that
Parrot use Lisp's triple equality test operators (one tests if two
things are the same thing, the second if two things have the same
value, and the third tests that they have the same structure). Jos
Visser argued (convincingly I thought) that having three operators
with the same semantics might be a Good Thing, but using Lisp's names
(eq, eql and equal) for them would definitely be a Bad Thing.
Branching off from a thread about using catch as a statement
modifier á la if, unless etc., Michael Lazzaro waxed
philosophical about the distinction between core and library. He
wondered if putting syntactic sugar into CP6AN and then having almost
everyone install it anyway wasn't a false economy. He went on to
defend the idea of the catch modifier.
Larry didn't agree. He suggested that a better way would be to look at
some kind of pragma which would make err (the low priority form of
//, aka 'defined or') put an implicit try around its left hand
argument. Michael still wasn't keen, but he wants to use undef to
stand for a SQLesque NULL.
Luke Palmer doesn't like the C Comma -- the one that lets you write:
while $n++, $foo > $bar {...}
He does like the semantics though, so he proposed renaming the C comma
and calling it then. People liked the idea of changing the name
because, if nothing else, it would mean one could write @foo =
1,2,3; and get a list with three elements rather than a one element
list containing the number 3. However, they weren't necessarily keen
on then as the new name. Damian wondered if we shouldn't just
insist on
while do { $n++; $foo > $bar } {...}
And then people started coming up various synonyms for 'and' in Latin like ac, cum et cetera. Larry hasn't ruled on any of the options yet.
Luke Palmer once again demonstrated his mastery of the telling question by asking a series of questions about runtime properties. Larry's answers, both to the immediate question and in the thread that followed make for fascinating reading and leave us all waiting with bated breath for Apocalypse 12 on Objects.
I'm afraid I'm going to punt on attempting to summarize the thread though; Larry's always hard to summarize when he's introducing anything new. You really should (at least) read his initial sketch though -- role based object orientation looks (to this reader at least) like a brilliant idea.
groups.google.com -- Larry outlines his current thinking
I've still not got 'round to getting the link shortening in place I'm afraid. For some reason the appropriate modules don't seem to want to install on my G5. Maybe next week.
Leon Brocard has taken on the role of Pumpking for Perl 5.004 and will not be appearing in these summaries for the duration of his reign out of respect. After all, being a pumpking requires a kind of dignity that would be incompatible with being a running joke.
If you find these summaries useful or enjoyable, please consider contributing time and/or money to the Perl Foundation to help support the Perl 6 effort. You might also like to send me feedback at [email protected]'>p[email protected], or drop by my website.
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
www.bofh.org.uk -- My website, "Just a Summary"