The Perl 6 design team met by phone on 28 October 2009. Larry, Allison,
Patrick, and chromatic attended.
Larry:
- unified nouns and terms in the grammar into a single category
- they're really the same thing
- did more spec work
- worked on global linkage between separate compilation units
- kicked the
GLOBAL:: package out of core
- the linker has to pull all of those things together
- different units have different ideas what belongs in global namespaces
- never specified that I wanted decimal literals to show up as rationals
- documented that literals stay exact as long as they can
- there was no specification if you match an undefined variable inside a regex
- now it warns and fails to match, rather than matching
''
Patrick:
- if you were looking up out of an aggregate?
- I'd expect to get a message about an undeclared variable
Larry:
- trying not to propogate magical undefinedness without more help from the user
Patrick:
- does it throw the standard "use of undefined value" warning?
Larry:
- it fails to continue to match
- lots of places Parrot and Rakudo throw exceptions I think ought not to be exceptions
- that's been getting better over time
- people continually try to use angle brackets for lists of numbers
- we ought to make them more DWIMmy in terms of elements, but not the type of the whole list
- Carl pointed me at a rant of Guido's about why Python didn't take rationals from abc
- I decided that the default
Rat type should not be infinite precision
- we can make one available
- by default, it maxes out precision at something outrageous, like 64 bits for numerator and denominator
- something that'll be easy to calculate and detect overflow on a modern processor
- won't try to go beyond that, which'll trend to overflow
- decided to break the symmetry with integers
- integers don't naturally expand geometrically in terms of accuracy required
- clarified the semantics of private accessors
- they're very primitive, though we're mulling changes to the syntax
- currently feels a little kludgy
- the AST entry in a
Match object only gets set explicitly to an AST tree node
- no longer defaults to the string
- the
$() form will default to the string, if there's no AST
- you can still get the AST/string semantics that way
- now you can test
.ast directly as a boolean to see if you have one
- holding forth on #perl6 and answering questions
Patrick:
- watched as others took care of the Rakudo release
- I like to list that as an accomplishment
- worked on the new implementation of NQP and the regex engine
- it's going extremely well
- it passes all but one test from the Parrot test suite for NQP
- I haven't bothered to make it parse POD comments right yet
- worked on native support of grammars and regexes last night
- worked on having NQP self-host today, compiling its own grammar and action methods
- there's one runtime issue with initialization
- then I have to fix up the makeful
- then it'll be entirely self hosted and won't need Parrot's NQP or PGE to build or run
- very impressed with the new grammar and protoregex features
- makes it really easy to put this stuff together
- frighteningly easy
Larry:
Patrick:
- if only you had come up with this idea four years ago!
c:
Patrick:
- the code reads naturally
- where it doesn't read naturally, I haven't put in features yet
- has contextual operators, defined-or, direct access to PIR ops as if they were function calls
- you don't have to box and unbox within a PIR string
- that gets handled automatically now
- NQP is really convenient for writing PIR subroutines
c:
- the generated code is ~60% smaller
Patrick:
- it's much smaller
- if you combine PIR instructions, NQP-rx knows the types
- you don't have to box and unbox between them
- an integer result that goes into an op that takes a string doesn't go through a PMC for the conversion
- fell out naturally from the PAST implementation
- had a long IRC discussion about
fetch and vivify opcodes
fetch now exists- don't expect a huge performance improvement, but I do expect our generated code to look nicer
- can replace eight or ten opcodes with a single opcode
- highly reusable in many new situations
- people will admire the efficiency of the generated code
- started a file with various questions to record for Larry
- hopefully that works out well
Larry:
- I have to be careful about updating the file versus the spec
Patrick:
- I'll point it out to you
- reviewed the Perl 6 book, the work of Jonathan, Moritz, and Carl
- very pleased with the progress they're making
- plan to contribute in the next couple of weeks
- Jonathan updated Rakudo to work with Parrot's new PCC on trunk
- there's a bit of a slowdown as a result
- mostly from parsing
- that's mostly PGE
- not too surprised about that
- won't worry about that, as we'll use a new parser soon
- we'll optimize the new parser
- need to get that a little bit further
- then I'll put out a public call for people to profile the NQP tests
- they're relatively small, compared to Rakudo
- they exercise a lot of the parser
- good place to find bottlenecks and improvements
- our next step is to convert Rakudo to its new grammar
- had a breakthrough last night
- obvious place to start: NQP's grammar
- it's heavily based on STD as well
- I'll copy that over to a branch in the Rakudo tree and we'll build it up from there
Allison:
- mainly working on PCC merge and cleanup
- a few fixes
- added a function for Will that I'd planned to add for 2.0 anyway
- released a new version of Pod::Simple, with lots of help from David Wheeler
- that makes me look forward to Perl 6 a lot
- the old format for parsing POD needs to die
- working on Pynie again
- asked for suggestions as to what to work on yesterday
- cleaning up old code as well
c:
- added
fetch
- will wait to see how that works out for NQP before adding
vivify
- did a lot of profiling, especially with Vasily
- Parrot trunk is as fast as or faster than it was before the PCC merge
- otherwise, fixing bugs
Allison:
- is it possible with the new NQP/PGE combination to use them as lex and yacc?
- in the language tarball, you can ship only PIR code, not NQP code
Patrick:
- the short answer is "yes"
- that's how NQP bootstraps itself
- keeps a PIR copy in the repo
- builds that copy into PBC files, which should be complete by themselves
- then it uses them to compile the source twice through to get source updates
- you could take those PIR files
- they stand alone
- compile them into PBC files and use that as a library
Allison:
- I want to ship the PIR files
- can ship Debian/Ubuntu packages of Pynie that depend only on Parrot
Patrick:
- I consider the PIR files the shippable artifacts
- I can set up Parrot so that those files are part of the Parrot repo
- periodically, with a discussion of periodicity, Parrot puts a copy of NQP files in the repo
Allison:
- do we need it in the tarball?
Patrick:
- that makes it easier for Pynie and other languages
Allison:
- I'd make NQP a build dependency of Pynie in the packages
- the tarball for Pynie only includes the PIR version of Pynie's grammar
Patrick:
- Parrot isn't completely standalone for this
- you can use NQP to build the PIR files for a parser and translator
- running the parser/translator does not depend on NQP.pbc
- the parser and translator will still depend on Regex.pbc and
HLL.pbc, which are effectively the new versions of PGE.pbc and PCT/HLLCompiler.pbc
Allison:
- we need that PIR library with Parrot
Patrick:
- there are four components
- they're separate now, but they'll be there
- the regex engine will be a standalone Regex.pbc
- there's a new version of
HLLCompiler
- those are the two biggies
- there's a PAST compiler which compiles Perl 6 regular expressions
- only necessary if you want to compile Perl 6 regular expressions
- then there's NQP itself
- I think everyone will want to have three of those four lying around
- every language (hopefully) will use them
- why not include them?
- NQP doesn't need to be in the Parrot runtime
- it can be in parrot-dev
Allison:
- my wariness comes from trying to maintain Pod::Simple outside of the Perl 5 core
- it's painful trying to maintain that on two different development cycles at the same time
Patrick:
- that's similar to what we have now with Rakudo
- Parrot and Rakudo have different cycles
Allison:
- I was hoping that moving NQP out of the Parrot repository helped alleviate that problem
- NQP could have its own release cycle
- it's an external module that people depend on and load when they need or want it
Patrick:
- I don't expect it to evolve much after January
- it'll be very, very stable
- the point isn't to make NQP powerful or add lots of extensions
- it's supposed to be simple
Allison:
- are Perl 6 grammars still changing?
Patrick:
- not much, in my impression
- I suspect they might evolve toward what NQP provide
- we have several months to try different approaches
Allison:
- what's in the repo right now will be there until 2.0
- I was toying with the idea of using CPython's parser and parse its AST
- still think we're better off using PGE in whatever form it ends up with
- looking for ways to make sure that we can still ship Debian packages right away
- even if it takes a while for NQP as a separate package to make it in
Patrick:
- I'll create a patch
- or check in an example with the four files
- I'll leave the existing NQP and PGE alone in the repo
- they'll remain at least through 2.0 and the forseeable future
- I'll set up Parrot to make it easiest for HLL developers
- if not necessarily packagers
- you can change that if you want
