Thursday July 02, 2009
Perl 6 Design Minutes for 27 May 2009
The Perl 6 design team met by phone on 27 May 2009. Larry, Allison, Patrick, Jerry, and chromatic attended.
- changed the
time function to return a
- thinking about the traits that have been bothering Jonathan and others
- have some changes to check into the spec when I'm happy with them
- thinking about the primitives we use to define
- breaks down into load and import
- thinking of establishing compile-time keywords for both concepts
- intended so that I can import from anything acting like a module -- an inlined role, for example
- otherwise trying to keep up with the flow of IRC
- working on the Parrot book
- changed its focus to a small, 100-page PIR book from a monolithic Parrot book
- the intent is to get something out for YAPC and OSCON
- will send out a draft for review
- will merge my changes into the repo later this week
- released Rakudo #17 last week
- was easy again
- 875 more tests since #16, so we pass 68% of the spectest suite
- finished implementing the
root_new opcode in Parrot
- cleans up a lot of the PMCProxy issues from moving Rakudo to its own HLL
- gained half of the speed we lost from the migration
- we'll get more back as we update more places that need it
- NQP never expected anything like that
- I have to rework some it and PCT
- haven't quite figured out how to do that
import in Rakudo
- the current implementation doesn't work
- will hopefully match with what Larry's putting in the spec
- it seems like the logical way to do things
- updated Rakudo's ROADMAP in docs/ROADMAP
- gives us an idea of dependencies and next tasks
- may also help people understand what blocks features they want
- the bonding period has ended for GSoC
- time for students to start coding
- everyone on the Perl 6 and Parrot projects is ready
- fixed some memory leaks in Parrot and Rakudo
- there are still some in Rakudo, but the web examples should be able to live longer
- did more profiling
- think NFG is important for Parrot in the near term
- have some documentation to write
- have been editing the Parrot book
- how's the command line for Rakudo coming?
- I expect to get back to that
- the "parens build captures" decision surprised me
- what's the rationale?
- I really liked "parens mean grouping"
- maybe I haven't reconfigured my worldview yet, but it feels messy
- when used in an argument list, it has the same effect as a capture
- it even works when they're used as a term
- they still mean that you have to look at what you're binding to and decide
- am I binding this to a scalar or to an array?
(1, 2, 3) bound to an array...
- I'm going to have to think about that
zip operator in slice context....
- is this three or one positional arguments?
- how many positional arguments are in this case?
- one slice
- you wouldn't want to write that
- what in the arg list distinguishes the use of the semicolon versus the comma
- inside of an argument list we have to recognize a variety of syntactic things
- comma, semicolon, colon, array or hash sigil, named parameters
- seems like captures need more information than just positional
- they need to store metadata about positional arguments
- I like the syntactic stuff showing up in the argument list
- but I don't want to handle them in three different ways
- I'll have to think about that
- haven't figured out how to deal with slice context either
- might say that the presence of a semicolon implies the presence of other parens
- the comma implies...
- that might be more consistent binding for a top-level list
- I half expected that answer
- I can see the semicolon as just a lower precedence grouping operator
- otherwise you have a semicolon that's just not there in every other argument list
- assuming that, the other commas form an argument list through the infix semicolon
- an array in there means Capture of Capture of Capture
- we were about to refactor List and Array in Rakudo anyway
- the question is "Do we really have a List type now?"
- Rakudo assumes that
- if we can unify args list with List, that's probably healthy
- I'd really like that
- that makes things a lot cleaner
- infix comma and infix semis now just create arglists
- or Lists
- if you define List as "something that has out of band metadata"
- any more decisions that you can make about that will help our implementation
- I probably won't get around to that this week
- we make syntactic distinctions
- we know that this is an arg list
- we treat pairs as named arguments
- we don't do that if we know it's not an argument list
- it stays positional
- that's the only distinction between an arg list and a List
- purely syntactic
- to summarize
zip($a, $b, $c) has three positional arguments
zip($a, $b, $c; $d) has two, the first of which is itself a list/capture