The Perl 6 design team met by phone on 12 August 2009. Larry, Allison, Patrick, Nicholas, and chromatic attended.
Allison:
- have time again
- restarting the PCC refactoring branch
- doing the function conversions
- now working on little details
- working on something in PGE's second stage
- a thrown but uncaught exception doesn't get caught at the top level runloop
- reports the exception
- dumps the error message
- goes into an infinite loop and never quits
- tracking that now
- also catching up on tickets, trying to resolve blockers for deprecated tickets
Larry:
- went to YAPC::EU
- revised my "Nothing Can Go Wrong" talk yet again and presented it
- had many good discussions with many people about many subjects
- talked about POD with Damian
- hopefully we can get progress there at some point
- people are starting to block on that a little
- in S06 we only add
@_ and %_ to a sub if they use them in the body
- that helps multidispatch work properly
- if you don't use either, you get an empty signature
- monitored the bikeshed about embedded comments
- stepped in with my decision when the time is right
- we've slightly dehuffmanized that syntax in a way that simplifies things and is highly unlikely to comment out more or less than people expect
- added in a new statement prefix,
void
- in response to YAPC discussions about putting an else on loop statements
- if you have a way of casting an expression to return
Nil, it falls out of existing syntax
- originally I used a
Nil cast, but Damian pointed out that we couldn't put multiple statements as an argument
- the
void prefix is more readable and allows the block form for multiple statements
- the more statement prefixes we add, the more it justifies having that syntaxtic device
- started the transition in the specs from
Captures to Parcels
- still a lot of work in that regard
- still thinking about the module loading algorithm, at Daniel's request
- waiting on my prototyping in STD
- thinking about Moritz's question about string typology
- the notion of polymorphic literals
- to what extend do literals allow themselves to behave as multiple types, depending on their use
- if a string literal is decomposed characters, can you get at the decomposed meaning?
- does it turn into graphemes?
- what happens?
- if you have some form of number, which numeric types does it turn into?
- that ties into the mystery of multiple dispatch, of course
- in STD, I fixed a bogus error message on malformed parameters
- especially for using a malformed type
- now it complains about an undeclared type
- used to allow
sub() at the front of an anonymous sub declaration
- disallowed that for consistency with the "If it looks like a function..." rule
- switching the assertion that it does, after the keyword
- the
nofun assertion has a problem
- wasn't checking the same thing as the other assertions
- didn't check if the identifier was followed by a single quote, hyphen, or an alphanumeric
- added that check
- added the
defines infix specced for importation without loading
- stole Rakudo's colon as a delimiter error message
- also added an error for using a closer as a delimiter
- many error messages were misleading due to a phantom semicolon added as a stopper
- I tried to chop that string off as the first attempt
- now it turns into a space, but they don't show the bogus semicolon
- hacked in the new embedded comment syntax
- temporary deprecation of old syntax which should go away rapidly
- now detects
#` without opening bracket and complains
- continued converting
viv and gimme5 to converge to the same output
- can emit nested grammars correctly
- chopped out a lot of useless boilerplate
Patrick:
- YAPC::EU was very productive
- met a lot of Rakudo hackers at the Rakudo BOF
- very helpful for discussing a "usable version of Rakudo"
- I have a list of those wants
- all but four were already in our ROADMAP
- gives me confidence in our plan so far
- announced Rakudo Star, "a usable release of Perl 6" in the lightning talks
- very positive reception there
- most of the buzz is the right kind of buzz I'd like to see at this point
- had a hackathon on Thursday
- also went very well
- new people started to hack
- adding features into the Setting, cleaning things up, etc
- Jonathan and I had a detailed ROADMAP discussion
- we put priorities on each item
- will put expected dates and such on the list
- only 24 items in the must-have category
- most of those relate to parsing and STD convergence
- expect that to land sometime by December, if not sooner
- it's necessary by January for us to reach our April target
- we have a good plan in place
- merged the Rakudo installation branch into trunk
- builds against an installed Parrot instead of the build tree
- fixing a few minor bugs there, but it mostly works
- cleaned up some of the C code, especially in multidispatch
- parameter types defaulted to
Any instead of Object, and I fixed that
- moved
print and say from PIR into the Setting
- making good progress writing things in Perl 6 instead of PIR
- worked on changing the angle brackets that created lists of strings
- previously they were part of the
quote rule, but now they're circumfix
- necessary to get colon rules working
- will be more work to get that right
- may hold that off to see how the
Parcel design works in the spec
- added the whatever forms of prefix operators
- made the embedded comment change from yesterday; Rakudo now follows the spec there
Nicholas:
- Jonathan asked about a minimal integration of Perl 5 with Rakudo Star
- had a long discussion about how to look up lexicals in Rakudo from an embedded Perl 5
- I fully support that work, as long as I don't have to do it
c:
- still refactoring runcores
- hope to check it back in very soon
- blocking on lack of encapsulation and weirdness of the code
Patrick:
- haven't seen
Parcel changes in the spec so far
- when will it be worth doing in Rakudo?
- should I wait for more to land?
- would it help if I played with it now?
Larry:
- wait a little more
- have the definition in there
- starting to put ramifications in there
I really like these reports.
thickas on 2009-08-17T08:13:16
I have been reading about P6 devel systematically since about 2001.
It seems to me that the tone of the reports has definitely changed for the better.
Larry especially seems far more positive.
Looking back at the excitement for want of a better world of the early years of P6, it appears to me now that the failure to share the burden, the hallmark of so many IT stuff-ups (in much smaller realms), was a cause of the first Parrot/P6 meltdown.
Usually this is most noticable in low capability IT establishments where its characterised by
- blaming others
- over work of those trying to make things happen
- abdication by those at least in positions of authority
- unwillingness to acknowledge ones share of the failure
It's consoling to see that it can also happen in the ethereal band of immortals responsible for the worlds greatest programming language,and even more encouraging that they appear to have dug themselves out of it.
Well done.
