The Perl 6 design team met by phone on 28 May 2008. Larry, Allison,
Patrick, Jerry, and chromatic attended.
Larry:
- mostly off for this long weekend elsewhere
- continuing to work on quoting roles
- they need generic support to mix in roles with parameterized strings as starter and stopper sequences
- that's an interesting problem, when mapped into Perl 5
- no support for generic roles or parameterized types yet
- I'll probably just do an
eval
Allison:
- reworked continuations in Parrot, based on our discussion last week
- I have very high regard for the value of reading through the commit logs
- found the source of the problem that way
- someone committed the problem about a year and a half ago
- now continuations work the way they should work
- we now don't try to make CPS respect the dynamic environment stack
- it's largely unused now that we don't store exceptions there anymore
- tracking down one last bug
- I can duplicate it
- it's an exception thrown, caught, and resumed from an
:onload subroutine
- looks like they get executed differently from regular execution
- first draft of the Bylaws and Articles of Incorporation for the Parrot Foundation
- hired a lawyer in Washington state for incorporation there
Patrick:
- added quite a few things in the Rakudo implementation
- added a new metamodel that looks like the Perl 6 metamodel
- with Jonathan's and Jerry's and Moritz's help, we converted the compiler tools to that model
- cleaned up some of the inheritance hierarchy in Rakudo
- builtin types report correct methods and types
- a Parrot Integer reports itself as an Int in Rakudo, down to the metaobject information
- fixed pair handling, especially for calling functions
- people are testing those in great detail now
- now it's obvious that Rakudo's and Parrot's and Perl 6's argument handling there somewhat disagree
- doing some PGE refactoring
- primarily fixing up its class hierarchy; looks pretty easy
- may move Rakudo's grammar to use protoregexes
- might help get the metaoperators working -- French brackets, for example
- if we don't get this soon, people might submit patches doing things the wrong way (multiplying new operators for various combinations)
Jerry:
- Google Summer of Code started this week
- the aggregated feed of Perl GSoC 2008 student and mentor blogs is available
- the students will report weekly status at the #parrotsketch meeting
- the students and mentors will report at #perl6-soc on irc.freenode.net on Wednesdays at 18:30 UTC
- all of the students seem to be on track now
- made some spectest changes
- made some changes to rakudo List methods, applied some patches
- made some Rakudo test changes, should make test management easier and allowing us to create private and shared lists of tests we want to run
- should make it simple for rakudo developers to specify a subset of test files, making focused development and focused testing easier
c:
- not a lot of energy for hacking for some reason
- applied a few patches
- cleaned up a few tickets
- talked with Andrew quite a bit yesterday about GC plans
- he has some good ideas, including a clever marking scheme for which I have high hopes
- mostly on the right track
- will write up some guidelines on profiling and optimizing
- have one idea to optimize keyed object attribute access
- otherwise really need to work on the PIR profiler
Richard:
- trying to plan a legitimate way to ascertain Perl 6 grants, given the donation from Ian Hague
- planning a process around that
- thinking about YAPC::NA and a grant process BOF
Allison:
- Patrick mentioned argument passing in his report
- we don't quite understand how it needs to work in Perl 6
- Parrot will support whatever Perl 6 needs, though it may not necessarily be the default
- one goal of argument passing is to make it lazy
- you don't have to parse the whole list to start pulling out parameters
- required parameter positionals are clear
- required positional parameters are clear
- you can pass in a required positional parameter as either a positional or named argument
- Parrot maps the positional arguments to positional parameters
- when it runs out of positional arguments, it starts checking named arguments
Patrick:
- that's not really what Parrot does
- Parrot fills positional parameters with positional arguments
- then it fills in named parameters with positional arguments
Larry:
- what do you mean when you say "named parameter"?
Allison:
Patrick:
- all parameters are named in Perl 6
- they can be filled by a named argument
- Parrot has parameters that you can fill only by position
- then there are parameters that you can fill by position or name
- but Parrot fills them opposite from how Perl 6 would expect; it chooses the positional argument over the named one.
Allison:
- I thought you needed a way to skip over a named parameter in a list
- and then fill in its value from the named argument list
- or scan the entire named argument list first, and then fill in positional parameters
- it sounds like this is different
Larry:
- the compiler should recognize arguments intended as named parameters
- it can set up a data structure for efficient access
- the other constraint is that any argument can depend on the value of a previous argument in the list
- you have to bind them in the order of declaration
- you go down the list
- for each of them, you look up in the named argument list
- to see if it's bound by a name
- if not, you take the next one from the positional list
Patrick:
Larry:
- yes
- that's the abstract view from the Perl 6 end
- one reason we invented prototypes is so that the compiler can know that the first n arguments are positional
- map any named arguments into positional without having to do the lookup
- that's primarily a sop to efficiency
- for a very small number of named arguments, brute force is probably faster
Allison:
- do you never have any parameters which are strictly only positional?
Larry:
- there's no way to write that
- other than writing a bare sigil in the declaration
- you're not giving it a name
- but you can't access it, because it needs a name
Allison:
- sounds like we want three different flags in Parrot
- one for a purely-positional argument
Larry:
- the optimizer might use that, if it sees a prototype
Allison:
- we keep the
:named flag
- for named parameters
Patrick:
Allison:
- we don't really have that
- we have named that acts like positional
Patrick:
- we have named that prefers positional, and then throws an exception if a matching named argument is also supplied
Allison:
- might have four flags then
- one that's either named or positional
- maybe one that gives priority to the positional
- not sure that's useful
Patrick:
- I couldn't come up with a case where that's useful
Larry:
Patrick:
- you can almost simulate that with slurpies in your code
- or sticking in dummy arguments
Allison:
- could come in useful if you have optional parameters
- you don't have to pass anything at all
Patrick:
- I proposed what you described as numbers 1, 2, and 4
- the existing
:named flag is named-only
- the
:positional flag is a named parameter that accepts positional arguments
Allison:
- I'm trying to get down the ideas
- I probably wouldn't use
:positional for that
- important to get the categories right
Patrick:
- I couldn't figure out a case where you have a named parameter that prefers the positional over the name
Allison:
- make it a positional and don't worry about it
- if you make it positional, you don't have to scan the argument list
c:
- look at Python's default parameter handling
- I think it may follow the one case you couldn't figure out
- not entirely sure
Patrick:
- is the answer that Parrot's underlying model will likely change to support what Perl 6 needs?
Allison:
- yes
- exact details yet to be determined
- as soon as possible so that you can use it
Patrick:
- it's been the subject of at least five or six RT tickets in the Rakudo queue
- they look like different problems, but they call come down to the same problem
- it's becoming a pain point
- I'm willing to implement it
- there are probably three or four related tickets in the Parrot queue
Larry:
- there was a question about writing Pairs various ways as arguments
- are they intended to be named arguments or pairs?
- how do you write the prototype for
list, by the way?
Patrick:
- I suggested putting colons in front of it
Larry:
- but
:a is always a valid term
Patrick:
- you can always look ahead for a fat arrow
Larry:
- I'd almost rather write
:> for that
- originally we always used the fat arrow
- then we put in the colons
- we wanted to use the fat arrow for arguments
- people seem to be used to the colon for named arguments, not the fat arrow
- maybe we should just bite the bullet
- you need the name as the identifier
- you don't need the general pair form
- the fat arrow makes a Pair not intended for a named argument, unless you do processing on it
- that'd be a simplification
- you can tell by just looking at it
- one is a named argument
- the other is just a positional parameter
Jerry:
- is there a method on a Pair that allows it to be passed as a named parameter?
Patrick:
- prefix vertical bar?
- S06 has options for making a Pair a named argument
- or a hash as a list of named arguments
Larry:
- we're trying to guess it based on the context of the argument list
- if you pass the list to a function call, it assumes you want named arguments
- otherwise you don't
- that might be guessing too far
- the
list function might want to parse more like parens
- but it behaves like a function
- you don't want to pass those as named arguments
- how do you tell the compiler that it's special
- maybe you want to make it a macro, but that's kind of weird
- maybe it's time to look at the cultural issue of how people want to write named arguments
- maybe we can simplify that
Patrick:
- there's a similar issue with the hash constructor
- you can kinda get away with it, because order is less important
- but it still exists
- it'd be interesting to look at the existing tests and Synopses to see the results
- there is some historical baggage toward using the fat arrow
Larry:
- the guy who wrote that Synopsis was familiar with Ada's fat arrow for named arguments
c:
- is there some sort of prototype declarator that says "It was an ordered list in the source code, and that's what I want!"
Larry:
- macros are a lot like prototypes
Patrick:
- Rakudo for now will treat them as special in the way that Pugs does
- it'll treat
list as a macro
- do something special, it's not a normal argument list
