This file is part of the Perl 6 Archive

To see what is currently happening visit http://www.perl6.org/

The Perl 6 Summary for the week ending 20040215

In his talk on Parrot at OSCON last year, Dan said that Parrot would have objects 'by the end of the week'. It's been a very long week, and it's not finished yet.

Right, venting over, time for the summary. I'll start with perl6-internals, as always. Actually, we're starting slightly before the usual start of the week because about half an hour after I sent last week's summary off I realised I'd completely missed a couple of threads.

Some minor decisions and timetables

Dan made a few design decisions and outlined a release timetable for the next release of Parrot (which was initially set to be Valentine's Day, but the appeal of February 29th for a Leap Parrot release proved to be greater).

groups.google.com[172.24.18.98]

Why didn't I mention this last week?

Jens Rieks earns a "Wow, cool!" from me with his parrot version of Data::Dumper. Way to go Jens. People were impressed.

groups.google.com

Supporting simple PMCs as keys

Stéphane Payrard posted a patch to support using simple PMCs instead of full on key PMCs for simple lookups. He and Leo discussed it, but the patch hasn't been accepted yet.

groups.google.com

Keyed access to UnManagedStruct

Everyone's favourite differently capitalized O'Reilly employee, chromatic (Maybe the new running joke should be my struggles to avoid using his name at the start of a sentence so we don't have a falling out cases), continued his discussion with Leo about keyed access to Unmanaged (and presumably managed) C structs.

groups.google.com

groups.google.com -- An example of chromatic's problem

Backward branch, fixed

Remember the problem with a backward branch that I said was Warnocked last week. It turned out that it was fixed before I posted the summary. They don't call Leo Tötsch the Patchmonster for nothing.

groups.google.com

Parrot system

Dan apologized for his recent silence on list, but thought he'd be more active from now on. He also announced that he was in the process of adding in perl 5 style system support

groups.google.com[10.0.1.2]

Parrot sort

Jens Rieks garnered more kudos with his implementation of a simple _sort function in IMC. Leo checked it in, and you'll find it in library/sort.imc in an up to date CVS distribution. Then, seemingly in his spare time, he fixed up some SDL related stuff for chromatic.

groups.google.com

RFD: Symbol naming and IMCC2

Melvin Smith posted a Request For Discussion about how IMCC2 will handle symbols and sigils. The issue seems to be that, for humans writing code, quoting symbols is a pain. Various options were suggested, but nothing appears to have been decided yet. (I quite like Leo's suggestion involving declaring lexicals with a mangled name for use in parrot, but marking it as being associated with an $unmangled_original_name.)

groups.google.com

JIT and branches under the Sun

Stephane Peiry found with the JIT on Suns; it seems that a loop that should terminate carries on forever instead. He and Leo worked on tracking it down, but the bug was still there by the end of the week.

groups.google.com

Rules for method resolution?

Okay, so I may have kvetched about the continuing lack of Parrot objects earlier, but Dan's definitely working on it. This time he's thinking about method resolution. In particular he wondered when

   findmethod P4, Pobject, "methodname"

should do the name resolution. In other words, should P4 contain the method that was current at the time of the findmethod call, or a proxy PMC that waits until the method is invoked to find the appropriate method. The discussion seemed to come down in favour of doing both.

groups.google.com[172.24.18.98]

Object spec

Dan noted that he'd checked in some major revisions to PDD15 (objects!) and suggested that people take a look. Simon Glover, Leo Tötsch and LF had questions.

groups.google.com[172.24.18.98]

Meanwhile in perl6-language

The thread that ate the mailing list

Luke Palmer doesn't like the repetition inherent in

   @sorted = sort { $^a.foo('bar').compute <=> $^b.foo('bar').compute }
               @unsorted;

He wondered if there might be some way of rejigging sort to eliminate the duplication and proposed a couple of spectacularly ugly possibilities. And then the world exploded. It seems that nobody (on perl6-language) actually likes the current signature of sort, but nobody can quite agree on what it should look like. You know things are getting hand when Dan proposes just using SQL's ORDER BY syntax (even though he was joking). Simon "Rubyometer" Cozens proposed:

   @sorted = @unsorted.sort(op => &infix:<=>, 
                            key => { $^a.foo('bar').compute });

Which, I have to confess, I rather like. Rod Adams demonstrated a truly painful looking sort function which this summary is too succinct to contain, see the link for details.

Personally, I'm amazed that a single library function could generate so much discussion. And there's more to come next week.

groups.google.com

groups.google.com

groups.google.com -- Feel Rod's pain.

Haven't I had this feeling of déja vù before?

Dmitry Dorofeev pointed everyone at Scharli et al's paper on Smalltalk Traits and proposed that Perl 6 use something similar. Which is what Larry proposed a few weeks back, except he called Traits Roles and propose that they also have (or mandate) state (the original Smalltalk Traits are stateless). Aaron Sherman wondered if the Emperor was actually wearing clothes by saying that Roles didn't seem to be substantially different from Java interfaces. I particularly liked chromatic's answer that "interfaces completely suck while [Roles] don't." My other favourite quote of the thread was from (who else) Larry: "The Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them."

groups.google.com

Announcements, Acknowledgements, Apologies

Well, I've thought about it some more, and I'd like you all to welcome chromatic as the Perl 6 Summary's official running joke. I don't guarantee to mention him every week, but I do guarantee that I'll always jump through hoops to avoid starting a sentence with his name when I do mention him.

If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:p6summarizer@bofh.org.uk, 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"