The Perl 6 design team met by phone on 29 April 2009. Larry, Allison, Jerry, Will, Patrick, and Nicholas.
Larry:
- let's start with the specs, in reverse chronological order
- we reserved hash notation in rule syntax, so it does not now have to be supported. It was kind of bogus anyway.
- subsets and enums were defined with a syntax that didn't allow traits, so we couldn't export them. Now traits are allowed right before the subset's
where clause or the enum's list.
- while messing with the enum syntax I decided that using
[] around the list didn't make sense, so that changed to (), to be consistent with the <<>> and ëû forms, which are defined in terms of parenthesized lists. In any case, some form of bracketing is required to prevent ambiguity with any preceding trait, so the parens may not be omitted, if that form is used.
- in S3,
temp and let are parsed as named unary ops
- there was an ambiguity in how Unicode bracketing characters were parsed. We can't allow one to many, but no there's no problem with many to one. That is, there are many ways to start a particular quote, but only one quote [character] that ends it.
- that's fine
- had to think of this, because we added Pi and Pf as valid characters, which they already were, because of the way we use the various angle brackets
- the
lines function now has a limiter on it, so you can tell it how many lines to input if you don't want all of them
- big news of last week was killing off prefix
= and renaming readline to get
- put the the
split function back to taking the delimiter in the first argument, as it was in Perl 5
- documented the
when statement modifier, which we'd all assumed was there, but wasn't actually in the specs
- STD hacking:
- tweaked the table of openers and closers to match S2.
- killed off the
= prefix operator, both there and in the tests, including the poor fish operator
- today I hacked in duplicate checking for type names
- been doing various simplifications
- got rid of the
fulltypename rule, Combined it with typename.
- last week got rid of the
extrapost rule, at Patrick's suggestion
Patrick:
- I don't remember asking for that, just asking what it is
Larry:
- it's a simplification that you triggered.
- better error messages about variant forms of
elsif
- modified the grammar for exportable subsets and enums
- noticed a few differences from the spec:
- the spec allows double angle brackets for enums, and I didn't successfully parse that
- the non-declarative enum that acts like a listop is now parsed as a listop, rather than being special cased
- refactoring to support the new caps method
- had to refactor PRE and POST
- the way chained and list precedence is reduced
- found a few parse tree malformations:
- the symbol is not copied up for the X operator brackets, so it was not having the correct precedence
- my nouns were dangling from the terminator nodes after them, and that was not good.
- driven by ongoing goal of making viv replace gimme5
- making gimme5 more regular in its output: it no longer uses auto-quoting inside curlies and it spells out the quotes exactly
- got most of the method expr correctly translated by viv now
- probably another couple of weeks or so before I can get viv doing everything gimme5 does
- the viv AST (VAST) used to bless objects into generic classes for (basically) precedence level. That's too generic for a lot of things -- you want to know which rule matched, so it now blesses to a class for each node. Those classes can be made to derive from a more generic class.
- people have been asking for per-rule for some time -- I probably should have done that sooner
Patrick:
- Rakudo release number 16, codename 'Bratislava", went incredibly smoothly. Really easy. What. I want.
- wrote a release guide: the steps you do to make a release
- can pass that off, when we want to groom other people to make releases, but really easy right now
- did lots of small fixes. Getting rid of deprecations and things.
- stringification of proto-objects in Parrot and Rakudo to match the spec
- regexps do the right thing in boolean context now
- regexps compile to a
Regexp type, rather than a Parrot subroutine, so we can do multi-dispatch on a Regexp now
Larry:
Patrick:
- fixed the
alpha rule so it includes _, which it didn't before
- inside character shortcut
\c, fixed so it allows whitespace, but not sure if it's part of the spec
Larry:
- actually the spec does have whitespace
Patrick:
- is that true for all the other
\ escapes, such as \x and \o?
- can I put spaces around the numbers in each of those?
Larry:
- probably
- the
\x already parses whitespace
Patrick:
- worked with Moritz to figure out how to traverse parse trees in Perl 6
- worked with Tene to get Rakudo to work in its own namespace, rather than the Parrot namespace
- found and fixed SEGVs [related to that]
- lots of little other things
- need to do blog reports and roadmap items.
- keep getting distracted by other more fun bug fixing things
- need to turn off all my IRC windows and write text
- planning to work more on getting Rakudo working as a HLL with Tene and getting Rakudo to build with an installed Parrot
Jerry:
- this week, getting set up for a Parrot VM workshop, working with the organisers [of YAPC::NA] and TPF, and put together an actual schedule, to get some structure.
- we have 25 or 26 people signed up already
- it's the weekend before YAPC::NA this year
- free at the Urban Mountain gathering place, in Pittsburgh
- it's a workshop for Parrot and languages on top of it
- learn about Parrot, PCT, Rakudo, etc
Allison:
- went to SF and up to Bellingham, Washington, giving Parrot talks last week
- went well, good feedback
- travel takes time, so not as much development work
- worked with Partcl, to get it up and running, to find out issues about building languages off an installed Parrot
- I have a list of three core things to fix off of that, plus helping Coke with Partcl
- made changes to language shell generator, because as I was writing the talk I found things that were hard to explain
- there has been some discussion on the TPF board about Richard's proposal for the Hague grant. This is ongoing.
- historically TPF directors have stepped down before taking funding
- Larry stepped down
- I only took travel funding
- not stepping down is legal, but controversial inside and out
- the work is definitely worthwhile
- collecting info for the 501(c)3 application for the Parrot Foundation
- it's the mother of all forms, about 27 pages long
Will:
- post the Parrot 1.1 release I updated docs.parrot.org to reflect that
- hopefully we can automate it for future releases, but it's already much easier than the old Parrot site.
- had stabs at getting Partcl running again
- it's at the point where it builds the C components
- some issues to iron out before the PIR will build
Nicholas:
- why did interpolated hashes get eliminated from rules?
Larry:
- all superseded by the longest token matcher
- it was a preliminary attempt to do a longest token matcher, but fit it into notation of hash, but it didn't really work
- it's a pain to implement it the way that it was spec'd
- I don't think that anyone really wanted to implement it
Patrick:
- it's a real pain to try to implement, but we have no strong need.
- we took it out, but reserved it so that it could go back in
- I didn't want to implement it
- I resisted it for three years, and I'm glad that I did.
Patrick:
- the main reason I wrote
create_language as an alternative to mk_language_shell was that others had checked in changes that I didn't want to rip out by fiat, as we're doing things differently
Allison:
- things that Rakudo is doing differently could be command line options
- they are additions, not fundamentally different
Patrick:
- one of the things I didn't like was it did use options
- you need to know in advance if you will end up with local PMCs or ops
Allison:
- if you don't know, you don't need them
Patrick:
- you have to figure out the things you need, retrospectively, and how they go into the Makefile
- it would be nice if they were present but commented out
Allison:
- have the same one to generate the Makefiles, and a new script to add things to the Makefiles?
- either you get everything all at once, when you don't need it or very little at the start, but you need to add it later
Patrick:
- adding it later is problematic
- you want to do releases, and to do so you modify the build scripts
- coming up with something able to patch the build scripts implies more modularity, which would increase the learning curve
Allison:
- so does a large section of the Makefile for build processes that you don't need
Patrick:
- also, I don't want separate Makefiles
Allison:
- you need that if you want to use installed Parrots; you can't have dynpmcs
Patrick:
- I was going to do it without those
- I've seen the way it's being done to avoid the scripts that are deprecated
- was going to avoid doing it from multiple Makefiles
Allison:
- (having everything in from the start), you have to understand all that's being dumped in
Patrick:
- if it's in the Makefile, but commented out, then it's already there, so you can just adjust the build
Jerry:
Patrick:
- if you're not doing anything that hits the target, then it doesn't show up
Allison:
- I can accept it with lots of comments, like some Linux packages do
- 5 line of commented out configuration
- 20 lines of explanatory comments
- "You can cut all this out unless you need X,Y,Z"
Patrick:
- Agree
- it would nice if the Makefile said "here's the stuff you need for dynpmcs"
Allison:
- I want command line options to turn it off if I'm making a new language and I know I don't need that
Patrick:
- Also I didn't like
make_language because it was making separate Makefiles. That's more that I have to maintain, co-ordinating changes between them.
Allison:
- it's cleaner to have Makefiles in subdirectories
- it's more the recommended procedure
- it has that going for it, but I'll take the complexity argument
Patrick:
- that's the gens
- I didn't want to rip out other peoples' code, but we can unify them
- I needed something for my talk in Norway and
mk_languages_shell broke
Allison:
- in the dynpmc there's a vtable function that is wrong -- documentation says that it's
setprop, but it's set
Jerry:
- the spec seems to be pretty stable now
- how can we increase the number of implementors and testers this summer?
- are there things that we can do from the design perspective, to make it easier for people to jump on the bandwagon and contribute?
Patrick:
- I was very encouraged by what happened in Norway.
- we ended up with two or three new contributors who have contributed since the workshop
- part of that, I hope, was how I structured my talks, so that they lead into the hackathon
- I broke out tasks that were hackable
- Rakudo has reached the point where it's possible to assign tasks
- Rakudo has really reached this point now, more so than a few months ago
Jerry:
- once something is added, all the tickets are assigned to moritz++ to write tests. He can only do so much.
Patrick:
- Moritz is a placeholder. It's not that we expect him to do them all.
- It's a way to tweak RT. You can look for all tickets assigned to Moritz.
Jerry:
- or create an anonymous spec test user
Allison:
Patrick:
- it's easy right now to use the drop down and assign an owner
- we could create a spectest account, but effectively Moritz's account is serving as a placeholder for "needs a test"
- if getting another field is easy, go for it, but a spectest user might be easier still
Jerry:
- lighting talks are a good way to introduce something in a short time
Allison:
Jerry:
- the Parrot VM workshop will be useful
- "Yes, you can do real things with Parrot. It's easy. We need your help."
- you can add Index
X<>s to the spec
- you can write tests
- you can make sure that the smartlinks inside the specs work
Patrick:
- my talk "Hacking Rakudo Perl" was 50% about Rakudo and roughly 50% about everything else in the Perl 6 universe that needs hacking
- what surprised me at NPW was that the people who came to the workshop, a lot of what was done was writing modules. We got IO::Socket, XML parsers, and a number of other modules, such as IO::Prompt.
- people building modules that would be for something CPAN-like.
- even discussions on how the modules could be organised into a CPAN-like repository
- I expect more of this this summer
- it wasn't like this last summer.
- it's because you can write builtins in Perl 6
- you can write classes. You can do things.
- you get something, even if what you get may not be reasonable :-)
- NPW was exciting because it was easier to recruit people into the project
- so far the best driver of Rakudo development continues to be people writing applications and modules. They really expose where Rakudo and Perl 6 need help. much more than tests.
- Carl Mäsak's talk about November was great in that respect. As much about why it is important to write modules and applications as about November itself.
- Rakudo was depicted as a Swiss cheese -- it covers specs, but there are holes
- applications sometimes intersect with holes, holes which the tests don't intersect. It's a really good analogy, and an important point.
- Carl's talk was by far my favourite of the conference
