The Perl 6 design team met by phone on 18 February 2009. Larry, Patrick, Allison, Jerry, Nicholas, and chromatic attended.
Larry:
- fixed STD so that if you added
A::B, it added A as a subpackage
- so as not to complain about a missing package declaration
- can now have
$! as a parameter
- mostly working over a lot of the error messages to be friendly to Perl 5 programmers
- if you use
do/while or do/until it now complains
- if you use
if or one of the keywords as if it's a function, it tells you what the problem is without saying "I don't recognize that function name"
- people coming from a Haskell background think they can write
1.. to get an indefinite range
- it now tells them what they should write instead
- fixed a bug which reported runaway strings which start and stop on the same line
- not really a runaway
- now it reports that only if the string crosses a newline
- in the spec space
- to accompany the ability to use a bare sigil in declarations as an anonymous name, now you can use a bare
:: to signify an anonymous package name or type
- allows us to have a package named
is without ambiguity
- blew away the
Main package; combined it with the GLOBAL package
- everything in the main program comes up starting in the
GLOBAL namespace
Patrick:
Larry:
- thought the distinction served no useful purpose
- continued doing spec work combining context variables with globals
- at least in terms of twigils
- realized that filehandles belong to the
PROCESS namespace, not the GLOBAL namespace
- continuing on the vein of
.Whatever on most normal operators builds a closure of one argument
- made
*.method do the same thing
- even in places which are not syntactically special, we can use
*.prime in a grep for example
- equivalent to putting
.prime in the curlies
- now we have a fairly general mechanism of writing closures of a single argument
- actually reads pretty well if you don't want the curlies
- we could go as far as to undo the special syntax on
whens and ~~ so you have to say *.foo to call a method
- still thinking about that
- would regularize the syntax slightly
Patrick:
- had a little emergency over the weekend, but things are fine
- improving Rakudo's build process to make it easier to build
- someone who wants to build it can get a copy of the repo and pass a special option to Rakudo's Configure.pl
- that'll download a copy of Parrot from the right revision and build it for you
- people who want to play with Rakudo don't have to play with Parrot dependencies
- Jonathan and I have most of the guts ready to start writing
Setting code
- we can start to write methods in Perl 6 instead of in PIR
- we'll gradually migrate methods which make sense to rewrite in Perl 6
- moving those over into the
Setting code
- that'll make it easier for people to hack on
- some things will remain in PIR, but we don't know what those are yet
- most of my plans for this week is doing more cleanups in the build process
- rewriting Rakudo's t/harness to remove dependencies on Parrot files
- have that mostly done
- writing some articles discussing Rakudo's new home
- how to get it, how to build it, and updating websites
Allison:
- working on Parrot's install process
- making it so that Patrick doesn't have to build and install a whole copy of Parrot to build Rakudo
Patrick:
- we'll need that for some time
Allison:
- trying to make it so that people who build and install packages have an easier time
- you won't have to depend on a Parrot build directory
- you can run against an installed Parrot
Patrick:
- I would like to get rid of the build tree dependency
Allison:
- the patch I have gets rid of most of the build tree dependencies
- there are a few header files in weird locations
- they don't get included in PMCs and dynops
- I've fixed all of the build tools
- all that's left is C-level stuff
- should probably send you to the patch to experiment with
- lots of stuff preparing for the release
- seems to be encouraging that we've been getting more novice questions
- seems to be an influx of interest here
c:
- talking to Richard Blackwell about YAPC
- Parrot and Perl 6 hackathon needs
- working on TODO/SKIP test review for Parrot
- also pondering bug triaging guidelines for Parrot
- having some discussions about release policies and deprecations (though mostly Perl 5)
- setting expectations early seems to help a lot
Nicholas:
- what projects did you look at, or did you look at things afresh?
c:
- Subversion's really early milestone release process was a real inspiration
- the Linux kernel's backwards compatibility policy was also
- not much besides that
Jerry:
- Ubuntu's long term support is pretty nice
c:
- I'm a little less thrilled there
- even six months time is a long span between releases
Allison:
- that's kind of a corporate support guideline
Patrick:
- I like knowing that Hardy will be supported for a few years
c:
- that's a risk for them
- how long are they going to support KDE 3 when upstream doesn't?
Nicholas:
- RHEL and other enterprise distributions support Perl 5.8 until 2011 or so
- but we haven't heard anything from downstream there
- and we only support critical security fixes there
c:
- I put in expicit language about vendors promising long-term security fixes
- that's your vendor's problem, not the problem of volunteers
Nicholas:
- in Perl 5, you used to do
package; with no namespace
- removed somewhere in 5.8.x
- was such a thing considered for Perl 6?
- you basically banned all unqualified variables
Larry:
- it was a hack in Perl 5
- I want to make new mistakes
Patrick:
- I expect to do Rakudo's next release next Wednesday
- that's a target anyway
- I'll be out of town this weekend
- we'll start its regular release clock with that release
- we'll do monthly releases
- that exact date will vary by a few days here or there until we get the release process down
Jerry:
- will you have a similar release structure as Parrot
- multiple release managers?
Patrick:
- yes
- I don't want to be the single release manager
- I'll probably do the first couple
- I want at least one other person to do some by May or June
- ideally a team
- the Rakudo release needs to happen very quickly after the Parrot release
- we won't be able to do this this month
- what do we need to think about for POD in Perl 6?
- what we have now is "DRAFT DRAFT DRAFT"
Allison:
- can you say "We'll target this version and update if necessary?"
Patrick:
- that's exactly what I've done so far
Larry:
Patrick:
- I expect to generate or write a fair bit of POD
Larry:
- it's amenable to mechanical translation
- someone should write a standard parser for POD
Allison:
- Parrot might as well stick with the standard
c:
- are you suggesting a Parrot-based POD6 parser?
Allison:
- if you develop a POD6 parser in Perl 6, could we compile it back down to PIR and use it?
Patrick:
- we'd more likely target NQP
- Rakudo expects the Perl 6 runtime available
- it'd be nice to say that that's just a PBC, but it's also PMCs and dynops
Jerry:
- makes me wonder how small we can make a Parrot distribution that only contains NQP as a language
c:
- that's the Parrot 2 proposal
Jerry:
- I meant ripping out all ops and PMCs you don't need
- maybe no IMCC
c:
- it's not PBC compatible though
Allison:
- he's talking about a version of Parrot built on as few basic opcodes as possible
c:
- no PMCs or ops written in C
Nicholas:
- I thought the computer scientists proved that you only need one operation to make things work, sort of a compare and jump
Jerry:
c:
- but you need infinite storage space
Jerry:
- disk space is cheap, and getting cheaper
c:
- but not infinite
- you can climb that asymptote all you want, but it keeps getting steeper
Patrick:
- the ultimate slippery slope argument
