All the Perl that's Practical to Extract and Report

Perl 6 Design Minutes for 18 November 2009

chromatic on 2009-12-04T01:20:53

The Perl 6 design team met by phone on 18 November 2009. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.

Patrick:

  • adding new features to NQP
  • checked in a copy to the Parrot repository
  • added the ability to create empty lists and hashes
  • added floating point constants
  • added array flattening into positional arguments
  • added statement modifiers
  • S05 changed with regard to subrule aliasing; updated NQP for that
  • so glad I created a new regex engine for this
  • that would have been difficult to do in PGE while maintaining backward compatibility
  • moved expression parsing closer to Perl 6
  • cleaned up literal handling
  • added the ability to have contextual variables look in global namespace and dynamic caller stack
  • simplified ability to set variables in other namespaces
  • continuing to bring Rakudo-ng branch up to feature parity with master
  • we'll release the Rakudo master tomorrow
  • mostly the same as October, but it uses the new Parrot calling conventions
  • spent my time working on the Rakudo-ng branch
  • we now have pointy blocks
  • updated to S05 interpretation
  • can parse numbers with decimal points
  • they produce Rats, not Floats, but I'm waiting for the spec to settle there
  • needs some cleaning anyway
  • statement modifiers now work
  • implemented Nil, after extensive discussion with Larry
  • works really well as an empty Parcel
  • implemented the .map method for lists
  • this version is lazy and can handle lazy lists
  • Jonathan and I updated dotty method operators to work correctly
  • still more to do there
  • worked on getting exported methods into a place where they're globally visible
  • currently they export themselves into the global namespace
  • works out pretty well
  • wrote a milestone report; completed the first half of my Hague grant milestones
  • should finish the rest of the grant by the end of the year
  • Jonathan's doing his amazing work on getting Rakudo pieces back in place
  • concentrating on method calls and class handling
  • we'll work on that through the next week
  • we'll pass a lot of the spectest suite in the branch by then
  • it's easy to get things to work
  • very few blockers in the new branch
  • most of the slowdowns are places where we were cheating but don't want to cheat anymore
  • have to do some work to figure out what the right approach is
  • started working on a new version of Partcl based on NQP
  • it's in the early stages, but it's worth trying to help Will there
  • so far it looks very promising

Allison:

  • working on tickets and small tasks this week
  • have no RT tickets left in my name
  • there are no RT tickets left at all
  • Will did a lot of fantastic work closing, rejecting, and migrating them
  • next week, I may work more on Pynie

Larry:

  • a bit under the weather this week
  • clarified the Nil semantics of empty blocks and missing branches
  • straightened up the Nil semantics for Patrick, as to what it actually is
  • the spec allowed a few of the phaser blocks to be statements instead
  • we opened that up to be almost all of them
  • they're now blorst -- block-or statements
  • Damian suggested we find some way of renaming those to blast, so we can have phaser blasts
  • unfortunately, they're block-or, not block-and
  • but maybe we can force that anyway
  • hankered for several months on this next one
  • when you alias a rule in the grammar, it does not suppress the original capture
  • people who wanted to give multiple aliases to an existing rule had to repeat it
  • that made sense in the original rule capture conception
  • after we added the dot form to suppress capture, it became easy to suppress a capture and alias a the same time
  • foo=bar in an assertion gives you both foo and bar in a capture
  • you say foo=.bar to suppress the capture
  • removed :panic last week
  • turned out to please the crowd
  • decided to execute :keepall this week
  • it's not very powerful, and it duplicates the semantics of .caps and .chunks
  • thinking a lot about Rats, as Patrick mentioned
  • design-wise, they consisted of a numerator and denominator of the same type
  • frequently you want a larger numerator than a denominator
  • settled on that as a normal thing
  • the default Rat type, even though it still has a 64-bit denominator, is just an Int on top
  • added a FatRat, a Rational with arbitrary precision on both numerator and denominator
  • easy to get in trouble that way, performance-wise
  • as Moritz suggested, Rat types are instantiations of the Rational role with the two types in question
  • Damian pointed out that STASH was the only type in all caps
  • changed that to Stash for consistency
  • Damian also pointed out that the CONTEXT pseudo-package was confusing
  • a singular noun implies one thing, even though it searches upward the dynamic stack
  • it's now DYNAMIC
  • individual frames are now Context; we distinguished them
  • worked on Rat normalization
  • they do not have negatives in the denominator
  • conversion to String now looks to see if the denominator is factorable into only twos and fives
  • if so, converts to straight decimal output
  • if not, it converts to a Numeric form in the String case
  • in the .perl case, it converts to the slash form
  • if it can convert conveniently into a decimal form, it does so directly
  • unbroke the check yada (bitrotted)
  • thus STD now allows forward-declaration of classes and subs
  • rearranged integer capture for Patrick, but he said he didn't need it
  • improved consistency of literal rules
  • changed to the new capturing/aliasing notation
  • fixed up the new blorsts
  • added a new Parcel type to CORE
  • thinking about the literal formats
  • a bad problem turned up with negated complex literals
  • they had a different meaning than if they weren't literals, in terms of negating the imaginary part
  • prototyped adding the pluses and minuses into the literal parts
  • thinking of going the other way
  • there is no literal form of complexes; always formed by constant folding
  • with recent changes to the semantics of angle brackets, a single literal inside angle brackets would recognize the literal forms we're getting away from
  • we could use angle brackets to emphasize the literalness of these forms
  • some performance ramifications to putting signs in literal rules
  • interactions with different sets of rules to apply to user input is questionable
  • that could run things you don't want to run in a tainting fashion
  • may be wise to separate literal parsing from the grammar's notion of literals
  • beyond that, working out the semantics of numification and stringification
  • when we want a basic version of those (give me this type) and otherwise (give me something that does this role)
  • the + operators probably do abstract numification, where it picks the type you want
  • if you say .Num, you get a Num
  • if you say .Rat, you get a Rat
  • Moritz pointed out inconsistent specs with regard to stringification and type objects
  • we expected them to stringify to the name, with parentheses, but other places expected them to stringify to nothing
  • if the internal uses of .str are low-level, inside say or print, we can make that one print the actual name
  • say Type.WHAT will give you the name so you can see it
  • most of the places we do abstract strings, we want to stringify
  • if ~ does the concatenation, we can have it check for undef, return null string, and give a warning
  • that maps to the use cases pretty well
  • most coercion operations probably want to use the abstract coercion
  • maybe
  • also probably removing is ref in favor of backslash
  • haven't specced that yet
  • want to play with the importation syntax
  • tag set notation is clunky
  • thinking about how to track foldability
  • what can you consider a literal, from a grammar point of view
  • otherwise, bug fixes

Will:

  • talked with Patrick about converting Partcl to NQP-rx
  • answering questions about that
  • hopefully Patrick will do all of the work
  • pushing people to close old tickets from RT
  • we can finally use Trac for everything now
  • now we have 600 Trac tickets to close

c:

  • fixed some bugs
  • working on medium term planning

Jerry:

  • are you releasing NQP-rx regularly?

Patrick:

  • I planned to make a new release a week before the Parrot release
  • didn't work out this way this week
  • it's evolving too quickly
  • but that's still the plan

Jerry:

  • will Parrot get a new NQP release in the Parrot releases?
  • sounds like yes, unless a language on Parrot needs a critical bugfix between the merge and the release

Patrick:

  • right
  • NQP will be very stable in the next month or two
  • already has most of the features I ever want to add
  • still has a couple of regex features I need to add
  • expect it to be stable before Parrot 2.0
  • could be wrong, as people jump to use it
  • but that was the point, and we'll see

Jerry:

  • blast could be BLocks, Alternatively STatements

Patrick:

  • blast is far less ugly than blorst