The Perl 6 design team met by phone on 08 April 2008. Larry, Allison, Patrick, Nicholas, and chromatic attended.
Larry:
- goofed off most of last week at Harvard, MIT, Yale, Columbia, and Bloomberg
- all the talks seemed to be well-received
- squeezed in a little bit of sight-seeing
- spent a lot of time thinking about things people are uncertain about
- particularly the big discussion of junctions
- finally decided to do something conservative
- said "Don't rely on anything fancy for 6.0"
- still thinking about comparisons
- how fail-soft they ought to be on type mismatches and undefined values
- how that relates to various contexts, such as sorting and parallel operations that want to suppress exception throwing
- thinking about the semantics of
leave and if we can nail that down
- or if each implementation will have to decide how primitive that is
- I think of it as unwinding the stack to a known point
- that's independent than throwing exceptions
- less primitive than falling off the end of a function
- more primitive than
return, or anything that decides to unwind the stack
- there are variants of
leave on other kinds of objects that probably are implemented in terms of throwing an exception
- maybe we're confusing some contexts
- looked at some of the
split discussion
- we should not have to inspect the pattern to look for captures
- there's now an
:all flag which returns captured delimiters as well as intermediaries in the split
- looked at
join
- the usages kept assuming it assumed to join on the null string
- seems like a danger flag to me
- nowhere in the test suite did it use the default-to-space behavior, since string coercion defaults to that anyway
- now defaults to the null string, which is more in line with expectations
- revised the test suite for that
- I believe Rakudo follows that now
- renamed
Str.reverse to flip
- the long list of tests that tried to finesse what's a string and what isn't is no longer necessary
- redefined the
reverse operation on hashes to return a list of pairs
- you can use those in more than one way
- there's also a
push method on hashes
- pushes values onto a list if you have multiple keys
- various wrinkles having to do with if you reverse something whose values are arrays
- breaks those out into reverse pairs, to try to preserve round-tripping
- hacked STD to allow the new
flip operator
- fixed a bug in the unrecognized quote operator to give the correct name
- helpful if you try to use a single quote without a space
- cross operators now treated as non-diffy; it was being too restrictive
- also hacked on the 32x32 Camelia
- some of the smaller icons need hand drawing
- at some point, you want to switch to vector based
Patrick:
- Jonathan did several things
- he's closing up his Hague grant
- we now have working parameterized roles in Rakudo
- they work more than they used to
- we can do MMD based on a parameterized type
- I've worked on a lot of PGE-related things
- also some code generation in PCT
- added an opcode to Parrot to search the lexical contexts of callers
- not just the outer context
- PGE and PCT can start to use contextual variables
- that simplifies a lot of things in both PGE and PCT
- the code generator in PCT puts in bytecode annotations to tie the generated code back to the HLL code
- now we can have real error messages about the HLL code, instead of a PIR location
- it doesn't actually report yet, but we have the data stored to report
- set up more Unicode stuff
- for the time being, it's a dynop in Rakudo
- seemed like the easiest way to start
- primarily giving regexps the ability to recognize Unicode character properties
- will add about 1000 new passing spectests today
- possibly more, but up to 1000 now
- we could break 10,000 passing tests
- also getting Rakudo to recognize regexps as regexps
- currently they're just Parrot subs
- trying to turn them into a
Regex type so we can multidispatch on them
- some of the pieces are in place in PGE and PCT
- next week, I'll focus primarily on getting PCT in order
- giving presentations at NPW and the hackathon there
- working on a roadmap for the next phases of Rakudo
- putting together some hackathon activities
- will include things that other people can help with
Allison:
- mostly worked on ripping out the calling conventions in Parrot
- went more smoothly than I thought
- wrote the code, hadn't run it
- ran it the first time and only had to change three lines to make regular subs work
- working on NCI subs now, as it needs different generation
- might have that done this week
- also working on the Parrot book
- it's mostly written, but needs some cleanup
- I'm generating a PDF of it, which is progress
- started converting Pynie over to Python 3.0
- mainly the
print statement is all I have left
- that's a fairly big change, because every test depends on that, but....
c:
- cleaning up organization of source code and headers
- will clean up some names
Patrick:
- on calling conventions, will that land for 1.1 or 1.2?
Allison:
- I'll merge back immediately after 1.1
Patrick:
- could it be two days after 1.1?
Allison:
- sure
- I want plenty of time to test it before 1.2
- but it's not an urgent thing
Patrick:
- the Tuesday that Parrot releases, I'll be on a plane coming back from Oslo
- on Wednesday, I'll be sleeping
- I'll do the release on Thursday
- releases are easy
- I'll spend some time trying to get Rakudo to build with an installed Parrot
- that's a good hackathon target
- that might make the release a little more time-consuming, but they're all very fast
Allison:
- I'm not changing the interface at all
- just changing the internals
- should mean fewer segfaults or anything
Patrick:
- I ask because Jonathan and I are eager to look at it to see what we need to do to fix up Rakudo's calling conventions
Allison:
- you might want to take the CallSignature as your only signature
- do your own unpacking
Patrick:
- that's one reason I asked
- we might do that
Allison:
- it's just a Capture with a little extra metadata
Patrick:
- Jonathan just discovered the slurpy block 24 hours ago
- it's a block argument to a function which occurs either at the beginning of a function or a normal position
Larry:
- it can come in as an adverbial block
Patrick:
- we can get what we need from named and positional parameters
- but asking Parrot to handle the slurpy block might be a bit much
- whenever we call a sub in Rakudo now, we pass control to another sub which performs unpacking and type checking
Allison:
- we have slurpy and named and slurpy named flags
- we'll need another option for "just give me the CallSignature straight"
Patrick:
- from a performance perspective on Rakudo's side, we can write a special opcode to do that for us
c:
- I'm not convinced you'll get speed that way
Patrick:
- it's a lengthy PIR sub, so it uses a lot of opcodes
Allison:
- it's a simple FSM, because that's cheap
c:
- what's expensive is copying data around and rediscovering type information
