Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Wednesday October 21, 2009
06:11 PM

Perl 6 Design Minutes for 30 September 2009

[ #39782 ]

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:

  • I like it much better

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:

  • if I do Cursor.pos...

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:

  • yes

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
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.