The Perl 6 design team met by phone on 07 October 2009. Larry, Allison,
Patrick, and chromatic attended.
Patrick:
- did more work on the regex engine
- coming along exceedingly well
- new engine written primarily in NQP
- started in a new GitHub repo
- the end goal is to come up with an implementation with built-in support for regexes and grammars
- current NQP supports neither
- NQP will be the component that handles regex support
- it'll be much more maintainable written in NQP
- pleasantly surprised at how much easier many of the constructs are to write in this form than in PIR
- have a stage one prototype for protoregexes
- necessary to implement the grammar for parsing Perl 6 regexes
- have most of the base classes for
Cursors and Match objects
- doesn't exactly match Larry's STD
- but I expect STD to match after Larry sees how I do it
- how's that for hubris?
- continuing to work on that
- would like to have a self-hosted NQP by this time next week
- mostly figuring out design issues, bootstrapping, and where the pieces go
- had my breakthrough on that on Monday
- now it's just however much time I can sit in front of the keyboard
Allison:
- worked on the PCC branch this week
- very productive
- the hackathon was a huge motivation for me
- most of the work I did was in the days before the hackathon
- I knew that if I could clear away known issues, I could make other people more productive
- wasn't coding as much as I was helping other people code during the hackathon
- both worked out well
- definitely like the hackathon idea
- working with Tene on finishing return handling code
- that's the last piece
- potential blockers are class time
- still working on getting a good space for work at University between classes
- too much time and trouble to go home and back
Larry:
- went to the LLVM conference with diakopter
- very informative
- forwarded chromatic's questions to Chris Lattner
- some good preliminary information
- worked on the semantics of warning exceptions
- classified them as control exceptions
- added a statement prefix
quietly to trap warning exceptions
- differentiated the use of
warn to emit warnings to talk to standard error
- the new
note function now emits a warning to standard error
- it's more informative
- suppressed in a different way from trapping an exception
- an outcome of going to the LLVM conference:
- both the people trying to implement Python and Ruby backends had some serious carpage about the overly dynamic nature of both language definitions
- thought about how we can avoid that in Perl 6
- using the same approach we defined for finalization, the default is now that after
CHECK time, any routine may be aggressively inlined
- unless declared ahead of time as prepessimal
- still coming up with good terms
- you have to predeclare in any of several ways that you're interested in wrapping a function to avoid aggressive inlining
- it's okay for the system to refuse to wrap a routine in that case
- does not close the door on partial pessimization
- if you're willing to inline the check for a wrap, you can get some optimization out of that
- the Ruby and Python people are trying to do that
- you can only get so far with that
- we should be able to make aggressive optimizations, unless the system requests otherwise
- need to distinguish routine type from hard or soft inlinable routines
- have
SoftRoutine and HardRoutine types now
- dehuffmanized methods on ranges to return whether
min and max are exclusive
- added
i as a constant, so you don't have to say 1i
- due to scoping, it shouldn't matter if you declare an
i routine
- yours will take precedence
- refined range definitions
- even if there's no
succ function, you get a range -- but can't do iteration
- wrote a long rationalization for why short-circuit
and should always turn a False into a Nil in list context
- pseudo-spec, apocrypha-spec or something
Cursor's string enum parsing works better- recognizes pair notation with strings
- moving files down from the perl6/ directory into lib/ for hygiene
- too much stuff for one directory
- refactored the symbol table code
- none of it uses hard references anymore
- various symbol tables stored in a global hash
- refer to each other via symbolic links through that hash
- much easier to debug symbol tables
- it doesn't chase links all over the place to make information you don't want
- stash objects attributes all start with
! pseudo-sigil to hide them from normal Perl 6 code
- hacked in the
quietly statement prefix
- finally made internal
import work correctly
- the
Setting now defines the Num package inline and imports constants from it
- reorganized
Cursor methods into appropriate sections
- hope to move some out to separate files
- the longest token JITter probably doesn't belong there
- the
loop construct now requires space between parenthesis and curly for consistency with other constructs
- also because I'm mean
viv raises the middle argument of a ternary operator to the same level as the left and right arguments- STD symbol table construction now longer adds
@_ or %_ unless it's seen them in the block
- Matthew found a terrible bug
- a block at the start of a file with the same identifier as a lexical scope was very confusing
- lexical scopes with signatures now have a signature variable to tell you that signature
my ($a, $b, $c) used to be considered a signature, added to the current pad- that was bogus
- it doesn't do that now
- generates missing signatures from placeholders or implicit
$_ semantics when reaching the end of a block
- fixed AST bugs in regexes, now returns atoms
repeat/while and repeat/until now require whitespace- lots of cleanups in STD
- getting rid of useless file-scoped contextuals
- chopped out
{*} stubs, as neither STD nor viv uses them
- refactored Perl 5 into a separate file
- loaded on demand
- unless you use Perl 5 regexes, you don't get the Perl 5 grammar
- started hacking a Perl 5 grammar which parses something that's not really Perl 5 yet
- no way to invoke the resulting code, either
c:
- fixed some Parrot bugs
- cleaning up some other things in Parrot
Allison:
- regarding development speed of PGE, NQP, etc and the Parrot core
- if we have a good, clean module strategy, does it make sense to host them externally?
Patrick:
- I'm already planning that NQP should be a separate module
- I expect that NQP will be the primary interface into PCT
Allison:
- which makes PCT an external module
Patrick:
- right
- we tell people to use PCT if they want to write languages in Parrot
- it'll be a fairly efficient compiler down to PIR
- even more than it is now
- when it comes time to write a PCT book, it'll be a book about using NQP to write compilers
- could be a standalone project
- if other people want to write other toolkits, that's fine
Allison:
- bytecode generation API should be core to Parrot
- other parts belong with PCT, if they're integral parts of PCT
- you may have synchronization problems if there are some parts in core and some aren't
Patrick:
- I have that same issue with the grammar engine
- we can recouple those components if it makes sense later
