Slash Boxes
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)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Tuesday April 20, 2010
11:09 PM

Perl 6 Design Minutes for 14 April 2010

[ #40318 ]

The Perl 6 design team met by phone on 14 April 2010. Larry, Allison, Patrick, Will, and chromatic attended.


  • on p6l, did a bit of bikeshed paint removal with regard to hyphens vs underscores
  • S02 now explicitly disallows both whitespace and unspace in top level of an interpolation
  • per spec change, when STD is parsing an interpolation inside quotes and looking for a possible postfix, we now presume that a backslash belongs to the quotes and is not an unspace
  • in the src/perl6 directory, renamed all Perl 6 .pm files to .pm6 to avoid confusion
  • this was necessary because the implementation of STD translates Perl 6 back to the corresponding Perl 5
  • the ambiguity was causing problems with tools such as NYTProf
  • Cursor.pmc now prefers .pm6 over .pm in any particular directory when searching for Perl 6 code
  • as usual lately, most of my hacking work was in improving the human interface of the parser
  • STD now distinguishes two final messages: "Parse failed" vs "Check failed"
  • STD now warns on attempts to smartmatch with True or False
  • STD now distinguishes continuable-but-fatal "sorry" messages from immediately fatal "panic" messages
  • sorry messages will eventually fail at check time
  • changed many of STD's semantic errors to use sorry messages when the parse state is not affected
  • modified moritz++'s conflict marker patch to be more like the Clang compiler's behavior
  • conflict markers now emit a "sorry" message and continues parsing one side of the conflict
  • also fixed a buglet that prevented it from processing the conflict marker if first thing in the file
  • while fixing the vws (vertical white space) rule for that, also changed it so that extra lines are now eaten with \V*\v for consistency
  • it had be using \N*\v
  • gimme5 now supports pointing to both ends of missing goal message
  • STD's "Couldn't find final ..." messages now use that capability to point to both ends of the error
  • standard quotes now also use the ~ compositor to set the goal and get that behavior
  • STD will now dwim <<op>> ("Texas hypers") better even if op contains angles
  • suppressed confusing backtracking on ~<< that produced a misleading quotewords error
  • some other patches
  • CORE.setting now recognizes the 'note' function
  • gimme5 now translates note to print STDERR
  • cleaned up some unneeded locmesses
  • now handles prefix metaops without spewing spurious yaml dumps


  • worked on TT #389
  • the actual fix was about two lines
  • spent a lot of time fixing tests around it
  • didn't like the original two-line fix
  • fixed it in IMCC by passing along the :nsentry flag
  • NQP-rx still depends on that feature
  • I understood from Patrick that NQP-rx doesn't need that feature
  • don't want to launch that before the 2.3 release
  • worked on a lot of smaller issues
  • worked on the Parrot Developer Virtual Summit
  • will talk about some process changes more, as there are details to work out
  • will work on GC as the next priority
  • useful for Rakudo in general and Parrot concurrency


  • catching up on mail and tickets
  • should get back to coding in the next couple of days


  • worked on the immutable strings branch
  • need a couple of changes in the Rakudo binder
  • now it's time to convince everyone else it's a worthwhile design change
  • going to work on bugfixes
  • will try to land the constant string cache
  • otherwise, added some optimizations


  • worked on Partcl
  • fixed a Parrot bug that broke Rakudo
  • does Rakudo need TT #389 in 2.3?
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.