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)

Saturday April 11, 2009
07:42 PM

Perl 6 Design Minutes for 08 April 2009

[ #38793 ]

The Perl 6 design team met by phone on 08 April 2008. Larry, Allison, Patrick, Nicholas, and chromatic attended.

Larry:

  • goofed off most of last week at Harvard, MIT, Yale, Columbia, and Bloomberg
  • all the talks seemed to be well-received
  • squeezed in a little bit of sight-seeing
  • spent a lot of time thinking about things people are uncertain about
  • particularly the big discussion of junctions
  • finally decided to do something conservative
  • said "Don't rely on anything fancy for 6.0"
  • still thinking about comparisons
  • how fail-soft they ought to be on type mismatches and undefined values
  • how that relates to various contexts, such as sorting and parallel operations that want to suppress exception throwing
  • thinking about the semantics of leave and if we can nail that down
  • or if each implementation will have to decide how primitive that is
  • I think of it as unwinding the stack to a known point
  • that's independent than throwing exceptions
  • less primitive than falling off the end of a function
  • more primitive than return, or anything that decides to unwind the stack
  • there are variants of leave on other kinds of objects that probably are implemented in terms of throwing an exception
  • maybe we're confusing some contexts
  • looked at some of the split discussion
  • we should not have to inspect the pattern to look for captures
  • there's now an :all flag which returns captured delimiters as well as intermediaries in the split
  • looked at join
  • the usages kept assuming it assumed to join on the null string
  • seems like a danger flag to me
  • nowhere in the test suite did it use the default-to-space behavior, since string coercion defaults to that anyway
  • now defaults to the null string, which is more in line with expectations
  • revised the test suite for that
  • I believe Rakudo follows that now
  • renamed Str.reverse to flip
  • the long list of tests that tried to finesse what's a string and what isn't is no longer necessary
  • redefined the reverse operation on hashes to return a list of pairs
  • you can use those in more than one way
  • there's also a push method on hashes
  • pushes values onto a list if you have multiple keys
  • various wrinkles having to do with if you reverse something whose values are arrays
  • breaks those out into reverse pairs, to try to preserve round-tripping
  • hacked STD to allow the new flip operator
  • fixed a bug in the unrecognized quote operator to give the correct name
  • helpful if you try to use a single quote without a space
  • cross operators now treated as non-diffy; it was being too restrictive
  • also hacked on the 32x32 Camelia
  • some of the smaller icons need hand drawing
  • at some point, you want to switch to vector based

Patrick:

  • Jonathan did several things
  • he's closing up his Hague grant
  • we now have working parameterized roles in Rakudo
  • they work more than they used to
  • we can do MMD based on a parameterized type
  • I've worked on a lot of PGE-related things
  • also some code generation in PCT
  • added an opcode to Parrot to search the lexical contexts of callers
  • not just the outer context
  • PGE and PCT can start to use contextual variables
  • that simplifies a lot of things in both PGE and PCT
  • the code generator in PCT puts in bytecode annotations to tie the generated code back to the HLL code
  • now we can have real error messages about the HLL code, instead of a PIR location
  • it doesn't actually report yet, but we have the data stored to report
  • set up more Unicode stuff
  • for the time being, it's a dynop in Rakudo
  • seemed like the easiest way to start
  • primarily giving regexps the ability to recognize Unicode character properties
  • will add about 1000 new passing spectests today
  • possibly more, but up to 1000 now
  • we could break 10,000 passing tests
  • also getting Rakudo to recognize regexps as regexps
  • currently they're just Parrot subs
  • trying to turn them into a Regex type so we can multidispatch on them
  • some of the pieces are in place in PGE and PCT
  • next week, I'll focus primarily on getting PCT in order
  • giving presentations at NPW and the hackathon there
  • working on a roadmap for the next phases of Rakudo
  • putting together some hackathon activities
  • will include things that other people can help with

Allison:

  • mostly worked on ripping out the calling conventions in Parrot
  • went more smoothly than I thought
  • wrote the code, hadn't run it
  • ran it the first time and only had to change three lines to make regular subs work
  • working on NCI subs now, as it needs different generation
  • might have that done this week
  • also working on the Parrot book
  • it's mostly written, but needs some cleanup
  • I'm generating a PDF of it, which is progress
  • started converting Pynie over to Python 3.0
  • mainly the print statement is all I have left
  • that's a fairly big change, because every test depends on that, but....

c:

  • cleaning up organization of source code and headers
  • will clean up some names

Patrick:

  • on calling conventions, will that land for 1.1 or 1.2?

Allison:

  • I'll merge back immediately after 1.1

Patrick:

  • could it be two days after 1.1?

Allison:

  • sure
  • I want plenty of time to test it before 1.2
  • but it's not an urgent thing

Patrick:

  • the Tuesday that Parrot releases, I'll be on a plane coming back from Oslo
  • on Wednesday, I'll be sleeping
  • I'll do the release on Thursday
  • releases are easy
  • I'll spend some time trying to get Rakudo to build with an installed Parrot
  • that's a good hackathon target
  • that might make the release a little more time-consuming, but they're all very fast

Allison:

  • I'm not changing the interface at all
  • just changing the internals
  • should mean fewer segfaults or anything

Patrick:

  • I ask because Jonathan and I are eager to look at it to see what we need to do to fix up Rakudo's calling conventions

Allison:

  • you might want to take the CallSignature as your only signature
  • do your own unpacking

Patrick:

  • that's one reason I asked
  • we might do that

Allison:

  • it's just a Capture with a little extra metadata

Patrick:

  • Jonathan just discovered the slurpy block 24 hours ago
  • it's a block argument to a function which occurs either at the beginning of a function or a normal position

Larry:

  • it can come in as an adverbial block

Patrick:

  • we can get what we need from named and positional parameters
  • but asking Parrot to handle the slurpy block might be a bit much
  • whenever we call a sub in Rakudo now, we pass control to another sub which performs unpacking and type checking

Allison:

  • we have slurpy and named and slurpy named flags
  • we'll need another option for "just give me the CallSignature straight"

Patrick:

  • from a performance perspective on Rakudo's side, we can write a special opcode to do that for us

c:

  • I'm not convinced you'll get speed that way

Patrick:

  • it's a lengthy PIR sub, so it uses a lot of opcodes

Allison:

  • it's a simple FSM, because that's cheap

c:

  • what's expensive is copying data around and rediscovering type information
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.