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)

Sunday November 01, 2009
07:43 PM

Perl 6 Design Minutes for 28 October 2009

[ #39828 ]

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:

  • I am, after all, lazy

Patrick:

  • if only you had come up with this idea four years ago!

c:

  • he's too lazy for that

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
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.