The Perl 6 design team met by phone on 02 May 2007.  Larry, Nicholas, Jesse, and chromatic attended.  These are the minutes.
 Allison: 
- I spoke this weekend at LinuxFest Northwest (so did chromatic). I was pleased at the response, including some C hackers who were interested in contributing, and a Perl hacker who implemented a way to parallelize our test suite during chromatic's talk. We'll definitely have to speak at more Linux conferences.
 
- A good part of my Parrot time last week was taken up preparing my talk, but I've gotten pretty close to a first draft on the PMC PDD. I plan to check it in later this week.
 
- Also, this week's "file of the week" is the C file for the core of the object implementation. We're working on refactoring that to integrate the new objects implementatiog
 
 Larry: 
- going to the History of Programming Languages at the start of June
 
- I'll give a short talk in the scripting language paradigm, past, present, and future
 
- cogitating on various design issues
 
- revised how autodefinitions of proxies work
 
- generalizes nicely to taking prototype objects
 
- attach a lazy closure to it to run on demand
 
- it returns a list of build arguments
 
- it can lazily construct a class when you call the first method on it
 
- use it with a role name to generate a role proto-object
 
- with initializers
 
- without committing to build an object to construct the role
 
- feed it to your C with your regular named arguments
 
- looks like a clean way to pass in type information without using funky name mangling
 
- working with someone to spec out pipeline IO
 
- working on various other IO specifications myself
 
- just getting my ducks in a row for summer travel
 
- working with fglock a lot on getting his v6 parser to parse STD.pm
 
- also to output P6 code closures, rather than Perl 5
 
- because Pugs already has good support for closures and can link to itself more easily than Perl 5 to Perl 6, that we can build the grammar tree and do subsequent parsing more easily than we can feed it across the gateway
 
- maybe that's the short way to a bootstrap
 
 Jesse: 
- how much work will it take before you can see if it's productive?
 
 Larry: 
- Flavio thinks that it'll be another couple of weeks before he has the v6 parser in sufficiently good shape
 
- that should give us good feedback even when running under the Perl 5 engine
 
- that still leaves the problem of bridging
 
- once you have that spitting out Perl 5 code, making it spit out Perl 6 code instead is probably not too much of a stretch
 
 Jesse: 
- are there parallelizable jobs?
 
 Larry: 
- down the path, the Haskell engine needs to provide more support
 
- I don't know what that would be yet
 
- once you get one backend giving out, other backends become more possible
 
 c: 
- my report is the same as Allison's
 
- working with Brad Fitzpatrick on parallelization
 
 Nicholas: 
- I want parallel tests too
 
- I tried to work that with Test::Harness, but it's ugly
 
- though I'd wait until TAP::Parser entered the core
 
 Jesse: 
- I want to raise the DLR thing
 
- just want to raise the question of why don't people consider Perl a target?
 
- does the new DLR stuff give a possible Perl 6 implementor more rope?
 
 Larry: 
- the .Net folks several years ago didn't want to support continuations
 
- they were okay with emulating it
 
- obviously if Ruby's running on .Net, they support continuations somehow
 
 c: 
 Larry: 
- continuations aren't required for the core features of Perl 6
 
- we've danced around the edges with things like resumable exceptions
 
- by requiring stack unwinding operations, resuming an exception can be returning from the exception handler
 
- if we want to write our own regex engine in Perl 6, it'd be awfully nice if we had continuations
 
 c: 
- unless it adds nice tools for building languages, I don't see much compelling use for it at the moment
 
 Larry: 
- if we get our stack working well, it might be a compelling target
 
 Nicholas: 
- my message on London PM was that corporate funding paid for the finishing of IronPython and Ruby on the JVM
 
- don't know how much work ActiveState put into their Perl port
 
 c: 
- it's an attempt to appear relevant in the face of hype
 
- if there were Fortran on Rails, Sun and Microsoft would be falling all over themselves to get Fortran on the JVM and the CLR