The Perl 6 design team met by phone on 16 July 2008. Larry, Allison, Jerry, Will, Jesse, and chromatic attended.
Larry:
- switched my laptop to Ubuntu for various reasons, mostly work
- helped me get a runnable Pugs too
- haven't worked much on the standard grammar
- mostly thinking about refactoring the names
- thinking about various other questions people are asking
- just checked in a revamp of the closure semantics
- a little under the weather too
Allison:
- almost entirely absorbed by OSCON this week
- hacking a little bit on the three remaining test failures on the pdd25cx branch
- Patrick gave me some information on the PGE failures
- we'll work on that tonight
- hopefully will merge in the branch finally
Jerry:
- haven't done much this week
- will report for Patrick and Jonathan though
- Patrick's working on lexical issues
- he's much closer to understanding how Parrot can handle them
- he's also working with HLL to get it to work within PCT
- then he can make it work within high-level languages itself
- that'll let them use the same named classes as Parrot's base classes (for example,
Integer) instead of funky workarounds - Jonathan added
enum support - fixed a couple of segfaults
- something like 910 new spectests passing between Parrot 0.6.3 and 0.6.4
- that's a great number
- much of it came from the Summer of Code project for the Perl 6 test suite
- Adrian and Moritz have been a big help there
Patrick: (in a followup)
The primarily reason we want HLL support is to take advantage of HLL type
mapping, so that str register-to-PMC conversion automatically gives me back a
Perl 6 Str object instead of a Parrot String PMC.
Same for int to Int, num to
Num, and ResizablePMCArray to List
conversions.
c:
- things are pretty slow
- traveling and haven't had much time
- still working with Andrew on the GC; he's making progress
- helping Allison; we're getting close
- will definitely start the string branch very soon
- maybe we'll merge that back in stages
- waiting for some guidance on the closure issue
Will:
- Parrot 0.6.4 came out on Tuesday, thanks to Bernhard
- no major new features, although the NEWS listing has lots of little updates
- hopefully will get the concurrency branch merged by the next release, to make it 0.7
- I hate Subversion
- I wonder when we're going to update RT on perl.org
- and that's it
Jesse:
- talked to Richard last week about other interesting funding sources and corporate support for Perl 6
- he's working on that
- general strategizing on that for pushing implementations forward
- sounds like the hackathon is fairly set post-OSCON?
Allison:
c:
- do we have a sense of prioritization of features, or is that up to implementors?
Jesse:
- it's been up to implementors so far
- every time I've asked, each one has strong feelings about how to prioritize
c:
- I mention it just because I believe that giving people something productive to experiment with sooner is very useful for marketing
Jesse:
- I've talked to Flavio about this, for example
- wondering if there are subsystems of features that could come before others
Jerry:
- what I really want in Rakudo right now is IO so I can use it for work
- it's limited
- you can't do sockets, basically
- that probably won't be fixed until it's fixed in Parrot
- that's Parrot blocking for Rakudo
- as far as other implementations go, there are early features that all implementations share
- I think Larry's said before that the Synopses deliberately don't look ahead too much
- if you do operators before you do objects, that's a way forward
- although parameterized roles are funded work
- and volunteer work
Larry:
- I do use those in my work
c:
- I don't have a sense of our priorities
Larry:
- Perl 6 will be very useful when it does its Perl 5 subset in a way that's better than Perl 5
- that said, there's a danger when Perl 6 gets used in anger by people who start to rely on transient bugs or workarounds for missing features
- there needs to be expectations management
Jerry:
- possibly the best way to do that is to say "Only use what passes in the spectest suite"
Jesse:
- unless there's a way to disable unstable features outside of devel checkouts
Larry:
- but what does it mean that a feature works?
- closure cloning might almost work, but there are some bugs
- we can put a large warning in the documentation that not all features are stable or final yet
- or run into the problem of installing Cabal features to run Pugs
- some packages are under development
- you're lucky if it all works
- it's easy to get an explosion of things that don't all work with each other
- I don't profess to have the right answer
- I don't think there is a right answer
- mostly I think the order of implementation will tend to iron itself out
- everyone has an itch to have the basic stuff working
- everyone has extra itches which may not correspond to other itches
- they're exercising parts of the design that other people aren't exercising
- I want convergence to happen
Jerry:
- provided you don't go crazy trying to keep it all in mind
Larry:
- there may be a need to name development subset versions
- maybe pre-6.0 isn't a sufficiently rich naming scheme
- at least it's an interesting problem
Jesse:
- it would be interesting to find a name for subsets of what will be Perl 6
- the trivial functional subset of Perl 6 that Audrey made in a week was a working subset of Perl 6
Larry:
Jesse:
- I've had multiple implementors prod me about how to name or label these things
- here's a thing we've targeted
- we can talk about it as an entity, even if it's not 6.0.0
Larry:
- there's a sense in which the true name is the list of all of the tests it passes
Jerry:
- Rakudo has a ROADMAP
- Patrick keeps it updated
- but he had some unanswered questions in that thread
Larry:
- there's a long list of things blocking from the Parrot end
- a lot of things are in perpetual redesign
Allison:
- I finished the last Parrot design document
- we need resources to implement them
Jerry:
- there were a lot of early prototypes that made it 60 - 80% of the way
- a lot of these features are waiting for a final thing
- it's no fun coding HLLs for a moving target
- they want to wait for the final version, rather than rewriting it several times
Jesse:
- the Rakudo ROADMAP is just a bullet list
- no subtasks, no estimates of effort
- a list in rough priority order
- it could use a couple of more levels of information
Jerry:
- we could make it a hackathon task
Jesse:
- I'll only be there for a couple of hours
Jerry:
- we could pull in some time earlier in the week
- why don't we call these chunks of features "traits"?
- that's an unused term
