The Perl 6 design team met by phone on 15 October 2008. Larry, Allison, Will, Jerry, Patrick, Nicholas, and chromatic attended.
Patrick:
- presented at the Pittsburgh Perl Workshop
- talked into being the keynote speaker about Perl 6
- gave a more direct talk on contributing to Rakudo and the test suite
- I don't think I even presented a single line of PIR at the conference
Allison:
- I consider that a great success
c:
- depends on the line of PIR
Patrick:
- I took the MMD failures out of the regression suite temporarily
- didn't want to go into the weekend with test failures
- we're still waiting for a fix there, but there's no particular rush
- 4409 tests passing now, up slightly from last week
- up slightly from even yesterday (30 more)
- worked with Jerry on getting
is export to work in Rakudo
- he's done all the work
- I just give him guidelines
- worked with Stephen Weeks to refactor PGE and PCT to use hierarchical names instead of string names
- we merged that
- but it broke TGE and Pheme and Tcl and another language
- PGE expects to use strings to match the match object classes
Allison:
- I'm pretty sure I know exactly which three lines of code to patch
c:
Patrick:
- I'll fix PCT to look in the right place for those
- if you don't hear that I've done it, I haven't beaten you to it
- cleaned up a lot of namespace issues in Rakduo
- fixed some mis-implementations
- trying to get nested namespaces to work so that Perl 6 can use them
- a lot of "two steps forward, one step back"
- updated the progress graph program
- now it shows the total size of the official test suite
- the graphs themselves will change a little bit
- I'll make an explanation of that
- still really want to get to lexical variables or Rakudo's container value model
- I'll do that this weekend, when I have uninterrupted time
Allison:
- cleaning up MMD problems from after the merge
- started a branch for the calling conventions
- Andrew Whitworth is working on that
- wrote a merging and branching guide based on my good and bad experiences
- thinking about things we can do to make merging cleaner
- maybe a checklist of people to talk to before you do a merge
- Patrick, that TODO test you added for the Complex PMC?
- I have it not segfaulting anymore
- it's always returning 0 now
- it creates a new PMC that hasn't been set to the right values
- I think it's a bug in the old proxy code
- we probably need to remove that old code and it'll fix it
Will:
- working on Partcl still
- have another test file parsing
- hoping to use the upcoming Parrot release as a new baseline
- the TGE issue is the blocker for that
- trying to close all of the easy tickets I can find in Parrot
Jerry:
- went to PPW last weekend
- it was very productive and too short
- spoke at Bug Labs about porting Parrot and Rakudo to the Bug
- they ported Perl 5 just before the conference
- some people were playing with it
- it's an ARM processor which runs OpenEmbedded Linux
- if it gets ported, we can run on other devices that size
Allison:
- that's definitely in our target range of uses
Jerry:
- spoke to someone about NVIDIA about using their CUDA GPU API for hyperop support
- that looks promising
- also made the
is export trait work
- includes tag sets
- committed failing tests for
import()
- working on passing those, may have that done by the end of the call
- discussed branching and merging philosophy with Allison
- put up a Wiki for the Parrot Developers Conference
- has questions which need answering
- I'll mail the list, requesting answers
- that'll give us an idea of logistical questions, including budgeting
Larry:
- on specifications, various simplifications
- expressions in conditionals are not special with respect to blocks that might appear in argument lists
- if you say
for map { ... }, it parses the way the user expects
- the block that the
for expects must occur where an infix is expected
- that simplification seems more DWIMmy
- I nailed down the operator modifying adverbs
- now applied on the basis of precedence
- no longer a special mechanism
Patrick:
Larry:
- there will be a few FAQs from that
- by and large it's a win though
- going back and forth on the subject of unpacking arrays and hashes
- someone noticed that the standard parser didn't actually handle those
- I went to add them
- discovered that the hash unpacking syntax using curlies was terribly ambiguous, especially inside a pointy block (arrow lambda)
- tried to rescue that, but in the long run decided that hashes have to be unpacked with signatures, rather than curly notation
- left in the square bracked notation for unpacking lists
- it contributes to clarity
- decided that enumeration types ought to define a
.pick operator
- you can do
Bool.pick and it'll return true or false
- thinking a lot about IRC and on the mailing lists
- how do you deal nicely about serialized token lists in the order that the tokens occurred in the original?
- how do those bind to signatures usefully?
- given that we want match objects to behave like captures
- did a lot of hacking on STD.pm
- somewhat driven by adding options to
viv
- it has several options now
- a match option attaches the old match objects to a position
- a positional option
- the main option is a
p6 option which attempts to spit out the exact Perl 6 as originally parsed
- discovered various places where I was throwing away information
- that leads to trying to keep track of tokens and match interstices
- also several other people are trying to use the STD output to try to produce other things
- they're discovering missing information that I've been hacking in
- it threw away all of the information on
elsifs and elses
- that made it hard
- removing cyclic references which prevent analysis of the tree as a DAG
- discovered a fundamental bug in the operator precedence parser
- reducing if there were any terms left
- it should have reduced if there were any operators left
- it didn't reduce any unary operators at the end as it should have
c:
- I fixed some bugs
- started looking at the DAG, but couldn't find much documentation
- do you have a getting started guide, or do you say "Look at this code and think really hard?"
Larry:
- it's the latter right now
- but I could at least put a help message on it
c:
- a list of node types and their attributes should suffice
Larry:
- that's the kind of documentation that quickly becomes a lie
- right now, it generates classes on the fly as it sees nodes
- it could at least tell you what it's doing as it's doing it
c:
- looked like it could be fun to play with for a weekend
Larry:
Patrick:
- right now, I can look up a namespace by an array, by a key, or by a string
- I can create a class by a namespace, a key, or a string
Allison:
- but not an array?
- I thought we fixed that
Patrick:
- we work around that in P6Object
- get look up the namespace by the array
- and then we look up the class by the namespace
Allison:
- we should be symmetrical about this
- your workaround should move into the Class PMC
Patrick:
- you have to do that for
subclass, isa
c:
Patrick:
- that specifically does not work
- that's what Stephen Weeks and I tried
Allison:
- submit a ticket
- there's no reason they shouldn't take arrays
Patrick:
- it's not a high priority at all
- just a discontinuity that stunned me when I ran into it
Jerry:
- there's a list of tagsets without commas in
is export
- STD.pm allows it
- but it seems to open shift-reduce problems with multiple terms in a row
Larry:
- two adverbs in a row are always considered one term
- just a sequence of adverbs
- whenever you parse one adverb, you look for one more
Patrick:
- they're not adverbs; they're terms
Larry:
- it works for terms too
- whenever you see a colon pair
Patrick:
- if I write
3 + :a :b
- the
:a :b is a term
- what kind of thing is that?
Larry:
- a list of pairs
- or a mapping maybe
Patrick:
- that's the same as saying
3 + 2
- the
:b would not be an adverb on the plus
- inside an argument list,
:a :b should act like two arguments
- not a list of two pairs
Larry:
- if it's coming in as a list of named parameters, it doesn't care
- if it's in a listy area, it gets interpolated as a list
- if you bring them in as a scalar parameter... you can't
Patrick:
- is it the came as
:a, :b?
Larry:
- in list context, yes
- when you're looking for named args, yes
Patrick:
- if I had a subroutine that took a positional parameter and a named parameter of a, and I call it with
:a :b
Larry:
- it acts like there's a comma between them
Patrick:
- is there a way to see them as a single term?
Larry:
- if you put them in parentheses
Patrick:
- they solve everything
- if I see
:a :b in an argument list, I have to translate as though they were separate arguments
Larry:
- I guess
- that's the way it works currently
Patrick:
- if we have a term that's a list of colon pairs
- we have to do some special unpacking stuff when we turn that into an argument list
Jerry:
Patrick:
- this is at compile time
- they have to be interpolated into the capture properly
Larry:
- now that we've changed how adverbs work, they stack up nicely in any case without any special rule
- if we removed the special rule, they'd work with the comma
Patrick:
- getting rid of the quantifiers with the colon pair in
noun?
Larry:
1 + :a :b would apply the :b to the +
Patrick:
- it gets weird when dealing with it inside the argument work
- we can make it work, but...
Larry:
- the phrase "make it work" means there's something suboptimal
- let me think about it a while longer
- the way the adverbials parse now would apply them to the same operator
- that was the main motivation for stacking them like that, to have multiple of them in the adverbial slot
Patrick:
- I thought part of that was for the filetest operators
Larry:
- that's another one
- let me think about that one
Patrick:
- we'll assume commas there for the time being
Larry:
Jerry:
- I changed the tests to use commas
