The Perl 6 Design team met via phone on 10 January 2007. Larry, Patrick, Nicholas, and chromatic attended. These are the notes.
 Larry: 
- aside from plumbing...
 
- continue to deal with the fallout from trying to define what it actually means to match longest tokens consistently across a grammar
 
- Luke and I had some interesting back and forth on that
 
- we're probably converging on something workable on that score
 
- thinking about the message from Steve Lukas
 
- "remember to outlaw declaring lexical variables twice in the same scope"
 
- there are some arguments on the other side
 
- thinking about what the default should be there
 
- thinking a lot about list comprehensions and how their syntax can fall out naturally from how we already express things with maps and for loops and such
 
- inside the opening bracket is now implicitly the start of a statement in terms of the syntax recognized at that point
 
- you can put for loops within parentheses now without explicitly saying do
 
- the notion of how you return a list of lists such that by default they flatten
 
- also such that you can get the result back as a list of lists if you want to
 
- some discussion about whether a list of captures can lazily decide based on context if people want a flat list or want it chunked
 
- other thoughts on syntaxes and defaults and such
 
- also the ever-going discussion on ints and nums and such
 
- need to install some of my decisions into S03
 
- I realize it's organized by braindump and not how an operator spec needs to be
 
- I'm about to reorganize it in precedence order as in the Perl 5 perlop page
 
- logical way to talk about ops, especially those that haven't changed
 
- we need to spec those
 
- it's a big fault of the Synopsis as it is now
 
 Patrick: 
- not much happened this week thanks to ice storms and school closures
 
- worked on PAST-pm
 
- have references working in Perl 6
 
- found that assign opcode doesn't work on arrays when you have a derived class of ResizablePMCArray PMC
 
- derivation from base class problem in Parrot
 
- yet another workaround to put in there
 
- keep running into the need for a new object model
 
- if you create a subclass from one of the existing PMC classes, some operations just don't work as you'd expect
 
- I have a workaround I'm almost ready to check in though
 
 c: 
- I'd like to see a TODO test for that
 
 Patrick: 
- worked on other things we need for the AST representation
 
- better HLL type management
 
- it doesn't feel right
 
- I'll work on some other things to let that sit for a while and see how it works
 
- giving a presentation this Friday in Austin
 
 Nicholas: 
- trying to go through a hundred patches a day on Perl 5
 
- feels like working at right angles
 
 c: 
- managed to implement the namespaces PDD work on the NameSpace PDD
 
- should have that whole PDD implemented by the next release
 
- that ought to allow better implementation of the metamodel
 
 Patrick: 
 Nicholas: 
- Larry, you mentioned "item context"
 
- is that a rebranding of scalar?
 
 Larry: 
- we use "scalar" to refer to the container
 
- the context we refer to as "item context" these days
 
- it's been there for a year or so
 
 Nicholas: 
- I missed that
 
- I like it better
 
- it's clearer
 
 Larry: 
- we didn't want "atom"
 
- "item" is close
 
 Nicholas: 
- what does your work program need from a Perl 6 implementation?
 
 Larry: 
- the coverage of the Haskell backend with the speed of the Parrot backend
 
- it'd be nice to have language support for the rule engine
 
 c: 
- does your program use that?
 
 Larry: 
- mostly OO
 
- I could use roles to speed it up some to avoid some method lookup
 
- still thinking about multidispatch semantics
 
 Nicholas: 
- maybe that's why Damian isn't here
 
- he's thinking about it too
 
 c: 
- he can't decide which Damian to send