The Perl 6 design team met by phone on 30 September 2009. Larry, Allison, Patrick, Jerry, Nicholas, and chromatic attended.
Allison:
- went to Linux Con
- spoke at Bay Piggies
- talked to the Unladen Swallow people
- refreshing the PCC branch for Parrot
- looking forward to a hackathon this weekend
- playing with Git, trying to get a handle on how people use branches
- I think we can comfortably use Git with SVN as the backing store if we fine-tune our processes a little bit
Patrick:
- working on updates to PGE
- going very well
- hacking in the beginnings of protoregexes today
- none of the code does anything, but I have the basic pieces in place
- will have the glue in soon
- entirely PAST- and POST-based
- PGE generated PIR
- now you build up your regexes using PAST nodes
- the compiler emits POST notes
- that can go to PIR or eventually PBC or another output format
c:
- even Perl 5, if someone were sufficiently crazy
Patrick:
- that's a possibility at some point
- get correct lexical and block handling for free
- patching that into the old PGE would take a bit of work
- had a local hackathon here on Saturday
- we updated complex number handling and something else
- also marked a lot of tickets in RT as LHF -- low-hanging fruit
- won't require heroics of information or compiler knowledge
- easy to find a bunch of tickets that novices can work on
- plan to continue working on the regex engine
- hope to pass the PGE test suite in a couple of days
- once I can do that, I'll start switching NQP to the new engine
- should speed up NQP
- NQP will support regexes and grammars
- then NQP can be the main interface for all of the compiler toolkit writers
- write and compile a program in NQP and you end up with a compiler
c:
- this will benefit from optimization stages for PAST and POST
Patrick:
- this will probably be one of the first stages where an optimization stage shows up
- we can optimize a regex tree at the PAST step
- seems likely
- haven't come up with a name for the new engine
- calling it PAST-regex, the regex portion of NQP
Larry:
- going to the LLVM conference on Friday with Matthew Wilson
- managed to get a pass from the right people
- if you have any questions, please send them to him or me
- decided to require parens on method calls with quoted names
- helps detect accidental use of dot as concatenation
- Patrick noticed that I used
temp and let in regular expressions
- documented that you can do that
- tired of the
defines infix; now we have a statement control import
Patrick:
- that one didn't last long!
Larry:
- it didn't work well
- the notion of an infix with
BEGIN semantics was problematic
Patrick:
Larry:
- you can import an inline module
- still trying to implement that
- redid the import code
- works for external modules, but not internal yet
- did a major overhaul of types
- split more of the abstract roles such as
Numeric and Integral
- added
Real and Stringy
- decided we were trying to do too much with pairs and mappings
- broke those into immutable and mutable types
- trying to document type relationships better now, especially in the numerics
- replacing
defines with import in the code
- Carl noticed the lack of report of nonexistent variables used in the default of a parameter
- easy to fix by localizing the appropriate flag
- packages and namespaces have much more informative ID fields, including lexical scopes
- contain file and line position now
- we can track lexical scopes even if they're not linked into other scopes directly
- a debugger can access other lexical scopes
- redeclaration messages on symbol conflicts now leaves off "lexical" on lexical collisions
- package conflicts now include the package name with the symbol
- much more readable
- infix operators now can perform various checks during reduction in the operator precedence parser
- the
.= rules, for example, is an infix that used to check that it was a Perl 5 version
- it didn't have enough information at that point
- now you can set a callback for the reduction point
- it has enough information to do an obsolescence check there now
- deleted the obsolete form of method with an adverbial
- have to decide what to do with prefix operators that leave out
prefix
- STD recognizes stubs with
... and doesn't complain about redefinition
- fairly intelligent approach
- if the top-level operator is
... or a friend, it's a stub
- not just textual analysis
- it even allows statement modifiers
- removed the grammar terms for
pi, e, and i
- they're constants in
CORE::
- upgrading
viv in various ways as Matthew discovers places where it doesn't propagate information into the AST correctly
- rad numbers now parse
- regexs now produce more correct ASTs
c:
- fixed some bugs
- will fix more bugs
- working on longer term planning for Parrot
Jerry:
- will the PGE changes speed up Rakudo more than the Parrot optimizations?
Patrick:
- I don't know
- it'll be hard to measure
- I get the advantage of all of the Parrot speedups
- the new system is a lot friendlier in terms of object creation
- it doesn't create as many objects as PGE does
- I've optimized down most of the backtracking state
- kept as a single
ResizableIntegerArray
- other objects created to keep track of the state of the match
- backtracking is basically clipping an array of size 10 to size 5, for example
- don't have to keep track of nearly as much information
Cursors and Match objects are much more immutable- much smarter about creating them
- creates them only when there's a mutating change
- should have a lot less GC pressure
- less jumping around
- smarter about backtracking points
- should be able to do a basic benchmark on the PGE tests in the old system and the new system
- that'll tell us quite a bit
- protoregexes should gives us a lot of speedup
- we get to avoid a lot of false trails by pruning a lot of trees that Rakudo's parser goes down
- can detect potential rules and jump right to them
- can avoid checking rules that can't possibly match
- if you're parsing an expression right now, we check for all of the types of statements, and then parse it as an expression
- if you do that for every statement, it takes a while
- lots of GCables created for those checks too
- we'll know in a couple of weeks
c:
- reducing GC pressure always helps
Patrick:
- the old version was faithful to the Perl 6 method
- every rule is a method with a slurpy hash
- the new version doesn't do that
- it gets the slurpy hash options out of the way at the beginning
- the rest can ignore it
- at least for now, it's not making empty slurpy hashes on every rule
Jerry:
- you talked about a cloning system outside of PGE before
Patrick:
- it'd be nice if Parrot had a way to access something as a hash and have it build up the hash only when you read them
- regardless of speed improvements, we need protoregexes and contextuals to make spec progress
- we'll go this way even if there's no speed improvement
- pointed out a problem with having methods on a
Match object with the same name as rules
- does having
Cursors not behave like Match objects present a problem?
Larry:
- inheritance fixes one direction of the problem, but not the other
- what a user views as a
Match object might contain the Cursor used to produce it
- might start from there
- probably needs to be a separate type from the user's point of view
Patrick:
- regexes still return
Cursors?
- it's easy to get to a
Match object from there?
Larry:
- the method that implements a regex?
- that returns a
Cursor
- what the user uses as what she thinks of as a normal regular expression, she gets back a
Match object
Patrick:
- you can't use the methods on
Match in a grammar
- the only problematic one was
pos
- there's a method conflict there
Larry:
- we might make the builtins uppercase
Patrick:
- I'm making them private with exclamation points for now
- I know you can't access them from subclasses
- if and when we decide to make them public, we can do that
Larry:
- maybe we can make a way of disambiguating them
- if there's a conflict in the rules...
- that part works pretty well
- the
pos comes from the base class
Patrick:
Larry:
- you can say
Cursor::.pos
- we can work with it in that direction
- try to disambiguate to the outside one, if it's something internal
Patrick:
- we could delegate the subscripting operator to the
Match object
- haven't needed that yet
STD doesn't do that- it treates the
Cursor as a hash in a few places
- could easily go through the
Match to do that
Larry:
STD cheats all over the places
Patrick:
- Perl 6 is being built by a bunch of cheaters!
Larry:
- something there represents an object attribute of some point
- most cheats are to make it work correctly on Perl 5
Nicholas:
- the Saturday before a Parrot release used to be a Bug Day
- has that fallen by the wayside?
- is that a good or a bad thing?
Jerry:
Allison:
- it's expanded into the week before a release
Jerry:
- we stopped advertising it in our release annoucements
- we've talked about having a dedicated hackathon day
- the Saturday before a release probably isn't the right day for it
Allison:
- we're doing a PCC hackathon this weekend
- the amount of time before the next release is a good idea
- we can merge some changes into trunk before that release
Nicholas:
- that distinction seems quite sensible
Allison:
- at one point, we had a bugfixing hackathon the weekend before the release and a hacking hackathon the weekend after
c:
- we're also trying to increase the bus number for features and branches
Jerry:
- the bugday was nice as a time to introduce new contributors to Parrot
- now we have other ways to get them excited about using Parrot
- downloadable and installable packages, for example
Maybe eventually....
We'll have an "Unladen Camel"?
