Rakudo.org

A newcomer to Rakudo and Perl 6 asked me "Where can I get a list of features that currently work in Rakudo?" Rather than try to build (and maintain) the list myself, I've built a wiki page for it at http://www.perlfoundation.org/perl6/index.cgi?rakudo_feature_status.

You'll notice that the page starts with a list of "common things that don't work" -- I'm hoping that people can use this to get a sense for the common pitfalls without having to search RT (which can be a bit slow). But below that we can start listing things that _do_ work.

Feel free to add/modify the page in whatever ways you think will be useful.

Pm

Are you interested in playing with Perl 6 and Rakudo Perl but can't figure out what to do? Here's an idea that came up during Jon Allen's talk "The Camel and the Snake" at YAPC::EU in Copenhagen.

For the past few years Microsoft has sponsored an annual Scripting Games competition, where they publish problems of varying difficulty levels to be solved using Perl 5, VBScript, Python, or other languages. I think it might be very interesting and useful to see people develop and publish Perl 6 solutions to those problems.

So, here's my idea: If you're interested in learning more about Perl 6, select one or more problems from the Scripting Games website, develop solution(s) for them in Perl 6, and then publish your solutions somewhere along with a description of what you like, don't like, learned, didn't learn, etc. about Perl 6 and Rakudo Perl.

One of the things we've observed from our experience with the November Wiki and other similar projects is that having "running code examples" and "real problems" is one of the best drivers for compiler and language development. I'm thinking that having people craft solutions to the scripting problems might do more of the same for Rakudo, while also sparking discussion and reflection on Perl 6 itself.

So, where to start? Start by obtaining and building a copy of Rakudo Perl, write and test your solutions to one or more problems, and post the results and your experiences somewhere for others to see. You can post to use.perl.org, your private blog, the perl6-users mailing list, or anywhere else you find convenient. The point isn't to develop a centralized repository of solutions (although we can do that), but rather to use the problems as a way to spread discussion, feedback, and experience with Perl 6.

I should also make it plain that people are very likely to run into some of Rakudo Perl's "rough edges" -- places where we don't yet implement key features or where they don't work exactly as they're supposed to. But to the designers and implementors that's part of the point -- we need to know where those rough edges are. Overall, I'm hoping that with the recent improvements to Rakudo Perl there won't be so many rough edges as to make the effort more disappointing than enjoyable. And there are lots of people eager to answer questions and help out on the perl6-users mailing list, IRC #perl6 (irc.freenode.net), and other common Perl forums. It's all about learning and improving what we have with Perl 6.

I look forward to seeing your questions and answers.

Happy holidays,

Pm

For some unknown reason I woke up at 3am on Saturday morning and couldn't get back to sleep. So, I decided I might as well use the time for some productive Rakudo hacking.

I decided to start by reviewing the spectest suite a bit. In the past couple of days I've noticed that although we've been increasing the number of spectests that Rakudo passes, we didn't seem to be shrinking the number of tests that are in the spectest suite but don't attempt to run (the grey area in the graphs). So, I decided to review the test files that we don't run, instead of the ones we do. I also reviewed the RT queue for patches to apply.

By 23:59 on Sunday, we had 526 more passing tests than we started with on Saturday. In fact, in the past two weeks Rakudo has increased its count of passing spectests by over 1,000. We're now at 5,790 total passing tests.

Here's some of what was accomplished this weekend:

• recognize the difference between array and hash subscripting.
• align with a change to S02 that now uses \c for decimal character encoding
• added the .kv method to Pair, to enable the pair.t spectests
• recognize more unicode codepoints (though still not all) as alphabetic
• enable the various unicode bracketing characters for quotes
• added the unicode versions of the infix hyperops we added last week
• added the p5=> "fat comma" operator
• cleaned up the readline method on IO
• recognize radix conversions in strings
• add +Inf, -Inf, and NaN processing
• add some workarounds so that Complex numbers work again (they broke with mmd)
• implement the use of the "whatever star" in list and array slices

Getting the "whatever star" to work was a nice surprise -- thunking the arguments to postcircumfix:<[ ]> turned out to be quite a bit easier than I had expected. Rakudo can now do things like @a[*-10 .. *-1] to get the last ten elements of an array.

Over the weekend Cory Spencer submitted several incredibly useful patches to fix array initialization in my() lists and properly refactor many of the list builtins. He has two more patches in the queue that I plan to review and likely apply tomorrow morning.

Overall, I'm very satisfied with the progress Rakudo contributors have made over the past couple of weeks. In addition to getting new features to work, there's also been a lot of internal refactoring and cleanup that will make things more efficient and help with the next phases of development. So, although I'm not sure that we'll be able to repeat the past couple of weeks, things still look very good for ongoing improvements to Rakudo.

Don't forget: we have a Rakudo Perl Twitter feed if you want to be notified of all of the new updates to Rakudo Perl.

Pm

So, here we are with the last Rakudo day before Christmas break. After a rather feature-filled last Rakudo day, I figured this week was time to take on some of the bugs in the RT queue.

masak found a bug in multiple dispatch, where it reported an ambiguity instead of no applicable candidates in cases where you had a bunch tied on constraints where none of the constraints matched. So, I fixed it. By the way, he was doing something pretty cool when he found the bug:

That is, multi-dispatching on the arity of the passed code block. (This worked, it was just when foo({{$^a + $^b + $^c }) was called, with arity 3, it gave the wrong kind of error.) You can do some wonderful things in Perl 6. :-)

Another quirk found through playing around with this was that if you wrote a sub taking a paramter with the sigil &, we needed to check that it was something that you could invoke. In Perl 6, that's the Callable role. So I stubbed that in, got Code to do it, and added a small temporary workaround to make typechecking work out on it since we aren't re-blessing Parrot subs into Perl 6 types just yet. And now if you were to call foo(42), continuing the example above, you'll get a type-check failure. Happily, multi-dispatch based on the sigil type just worked from this chance without any additional tweaks, which is what I expected.

Next up, I worked on adding a missing feature that had been requested: the .clone method. This in its most basic form, which I added first, lets you clone an object. The clone has its own state distinct from that of the original.

You can also change the values of attributes, such as in the S12 example:

Which just goes to show that while you can't teach an old dog new tricks, you can always get him cloned and teach his clone a new one. Anyway, added various new tests for the clone stuff, as well as unfudging those already there.

Smart-matching against arrays and lists had been requested, so I set about getting us an implementation of that. It supports * wildcard too, which can stand for any element. So you can now do things like:

Some other fixes in brief.

• Fixed doing private method calls with an indirect name, e.g. $obj!'foo'().
• Applied a patch and added a test from Ronald Schmidt to handle substr being invoked with a negative start and length (the patch should now give us the Perl 5 behaviour on this).
• Applied a patch from Chris Dolan to fix some grammar and nested namespace issues, and added the example from his ticket as a spectest.
• Reviewed, commented on and in a couple of cases where the issue was dealt with closed various other tickets.

Thanks to Vienna.pm for funding this Rakudo Day!

The Perl 6 design team met by phone on 10 December 2008. Allison, Jerry, Jesse, Nicholas, and chromatic attended.

Jerry:

• preparing to release a draft of the Perl 6 command line specification
• working on that today
• having trouble checking out Pugs repo on Windows
• will open that up for questions soon
• Patrick and Jonathan did a lot of work on Rakudo this week
• added some important features that make it feel like Perl
• list assignment and slices now work
• reduction operators
• inline PIR code
• Jonathan added hyperoperators and default values for class and object attributes
• some local Perl Mongers groups, Wellington and Portland, are doing Rakudo hacking sessions this month
• it's an excellent time to start playing with Rakudo
• about 4900 spectests pass
• we hope to reach 5000 by the Tuesday release

Allison:

• at the Ubuntu Developers Summit
• finished the IO branch
• Jerry helped greatly closing the Windows IO bugs remotely over IRC
• had someone compile Parrot on 64-bit Intrepid last night
• had a segfault there
• looked like an exception problem

Jerry:

• looked like an optimized Parrot, which has known problems on 64-bit

Allison:

• if we can get that fixed soon, we can get some Ubuntu help
• they have a service called PPA
• you upload a source package and it builds packages for multiple versions and architectures of Ubuntu
• we can have people testing nightly package builds
• people can subscribe to that build as a normal package repository
• we can do that even before we're in an official Ubuntu distribution
• I just have to set up the beginning bits
• should have that set up before next week's release
• working on Reini's install branch
• almost have the relevant bits committed to a fresh branch

c:

• reviewed Numbers PDD for Parrot
• needs some more thinking; bigint and bigfloat in particular
• concerned about autopromotion
• added some optimizations
• now we're at Rung 2 in Coverity Scan
• going to fix some bugs this weekend
• looking at other optimizations and memory management techniques
• agreed to manage Jonathan's role Hague Grant
• I'm concerned about spending only a month revamping the GC

Allison:

• the plan is only adding tri-color incremental
• it's going to be a conservative change

Nicholas:

• thanks to Leon, I've been watching python-dev
• they released Python 3.0 last week
• many things seem relevant to the Perl 5/Perl 6 transition
• they seem to have the same frustration that Perl has (and the whole world)
• despite many release candidates, they have a lot of problems reported only after general release
• lots of questions about which libraries work with which versions
• how to write software for the new version
• basic advocacy trying to keep people from thinking that 3.0 is stillborn due to libraries
• they made a big change to make everything Unicode
• this goes very wrong when you expect all filenames are UTF-8
• on some Japanese systems, some names are in UTF-8 and some are in Shift-JIS
• if you iterate over a directory, invalid UTF-8 names are silently ignored
• they're currently debating how to fix this
• there's the potential for scary data loss
• we should learn from their solution
• they haven't thrashed out one yet
• the problem is reconciling treating these as UTF-8 strings versus text the user can interact with

Allison:

• I was in packaging discussions yesterday
• Python 3.0 is a huge change like Perl 6 in that aspect

Jesse:

• yes, there are backwards-incompatible changes
• fundamentally the language is still the same

Allison:

• that's what we tell people about Perl 6
• you just can't run all of your old code on the new system

Jesse:

• Jonathan's Hague grant is now approved

The Perl 6 design team met by phone on 03 December 2008. Allison, Patrick, Jerry, Jesse, and chromatic attended.

Patrick:

• things are going well
• we fixed lexicals, which solves a lot of problems for November
• several people have worked on core features of Parrot to simplify things we're doing in Rakudo
• especially initializing subroutines, getting signatures correct, and MMD
• we're waiting for that to land soon
• Jonathan and I will clean up the compiler code after that
• it'll be a big improvement
• that allows us to fix up signature processing to work correctly
• affects multis and MMD
• helps fix binding properly
• we'll probably get list assignment and slicing working after that
• expect that in the next two weeks
• otherwise just fixing bugs and adding new features to Rakudo
• I owe Richard an updated Rakudo roadmap
• I hope to create something with more narrative prose for the next three months
• something publishable as a report, rather than a list of milestones
• it's part of the grant
• target audience: people who are curious about where Rakudo stands with respect to Christmas
• I'll also address our plan for Rakudo releases in the new year

c:

• restarted the Coverity scans and fixed up all of our Tier 1 errors
• they mostly are resource leaks and bad dereferences
• we should get bumped up to Tier 2 soon, which is more stringent
• otherwise, fixed some other bugs
• cleaned up some memory leaks
• reviewing Inf/NAN design soon
• also leading the review of our TODO/SKIP tests, so they all have tickets filed and get un-TODOed and unSKIPped as necessary

Allison:

• tracking down final test failures on the IO branch
• just about ready to merge in
• spent time reviewing Andrew's work in the calling conventions branch
• it looks like he has context-related failures in PCT
• spent some time looking at Reini Urban's makeinstall branch
• hiring an accountant for PaFo
• reviewing the copyright assignment from TPF to PaFo

Jesse:

• have you paid attention to the Synopses updates in the Pugs repository?

Patrick:

• I forgot to mention that they're there now
• lots of work on S07, Iterators and Laziness

Allison:

• are we deleting them from the perl.org repository?

Jesse:

• I thought the plan was to snapshot that occasionally

Patrick:

• Robert suggested we add an svn:external redirect there
• I believe he moved the POD to HTML generation to pull from the new location
• one of the two things needs to happen
• I moved the entire revision history when I imported them into the Pugs repository
• it would be good if the website resembled reality somehow
• the one synopsis not in Pugs is Synopsis 26

Jesse:

• I talked to Damian about that
• he's okay with a snapshot going in
• he'll be working on it further

Jerry:

• worked on the Perl 6 command-line syntax
• developing a grammar, more for documentation than implementation
• lets me test my ideas though
• that's progressing nicely
• expect to work on this the remainder of the week
• getting closer to releasing a draft
• have not yet been blogging about this
• it's about time now
• should I use the Pugs repository for my work in progress?
• not sure I want to be that visible at this point

Jesse:

• there's no huge reason to keep the work private

Patrick:

• you might get a lot of kibbitzing

Jerry:

• I don't need the distraction

Patrick:

• the mailing list discussion about S16 is an example
• that's a productive example
• but it might be interpreted wrongly if Jerry just ignores that

Jerry:

• are you making the Synopsis progress spreadsheet visible?

I'm pleased to announce that as of yesterday Rakudo Perl is now passing over 5,000 tests in the "official test suite" (spectests). You can see the current state of things in the graph:

Earlier in the week Adam Kennedy mentioned that it seems a bit sneaky to talk simply about the growth in pass rate without giving a basis for the number (1). This is a very reasonable question that comes up from time to time and in July I wrote a longish answer explaining why (2). The short answer is that the official test suite is itself a rapidly moving target so the percentages don't really say all that much.

The graph above tells the story -- but I've never really explained in a posting how we read this. The top of the grey area indicates the total number of tests in the spectest suite -- as of today (00:00 CST) there are 9,356 tests in the official test suite. If that number seems low to you, well, you're right. That's why were frequently asking for people to help flesh out the test suite -- more on this in a bit.

The top of the green area indicates the number of spectests that Rakudo is currently passing -- 5,004 as of today. So Rakudo is passing a little over half (53.5%) of the available spectests.

Within the "official test suite" there is a subset of test files that we designate as the "Rakudo regression tests". We maintain this list of subset files because there's little point in running Rakudo on a test file where we expect all of the tests to fail -- it just makes the testing take longer. So the top of the yellow area is the number of tests currently in the "Rakudo regression list" -- around 6,895 as of today. The blue area is thus the tests we can parse but not pass ("todo"), and the yellow area is those tests we can't parse but are part of the regression suite. Red of course is used to indicate failing tests, and we hope we don't see much of that. The tall red lines you see in the graph are places where the Parrot or Rakudo build was broken as of 00:00 CST on that day (and thus we were failing all tests).

So this graph indicates:

• the growth and rate of growth of the spectest suite (top of grey area)
• the growth and rate of growth in Rakudo's passing tests (top of green area)
• the ratio of Rakudo's passing tests to the overall suite (top of green versus top of grey), and
• the number of tests included in the Rakudo regression suite (top of yellow area).

You can of course determine other things from the graph -- these are the things I tend to be interested in.

The graph also makes it clear why knowing the pass percentage rate by itself can be misleading. Toward the end of June we were passing 25% of the tests (1080/4311) and today we're passing 50.3% of the tests. However, today's 50% is from a much bigger testing suite than what we were using in June.

There's also an issue of "what are the spectests actually covering?" For some insight to that, here are the current test results on a per-synopsis basis:

  Synopsis	       Spectests         Rakudo
  ------------------   ---------      -------------
  S02 - bits              1858         814  (43.8%)
  S03 - operators         1946        1156  (59.4%)
  S04 - control            654         287  (43.9%)
  S05 - regex             1536         848  (55.2%)
  S06 - routines           525         204  (38.9%)
  S09 - data                62          16  (25.8%)
  S10 - packages            49           0  ( 0.0%)
  S11 - modules             53          30  (56.6%)
  S12 - objects            591         289  (48.9%)
  S13 - overloading         51           0  ( 0.0%)
  S16 - io                 238          27  (11.3%)
  S17 - concurrency         28           0  ( 0.0%)
  S29 - functions         1750        1309  (74.8%)
  integrated tests          15          24  (60.0%)

  total                   9356        5004  (53.5%)

Here I've listed only those synopses for which we currently have tests -- the other sections don't have any spectests yet. As you can see, there are many areas of the Perl 6 specification that are undertested, and thus adding tests for those areas means our base "spectest" value will continue to grow.

So, ultimately my primary measurement of progress continues to be "how many tests are we passing", although through the graphs I do keep an eye on the percentage of spectests we're passing. For long term planning, I think that a really good milestone will be when we're passing ~15,000 tests; then I think we'll be able to say that we have good coverage of the Perl 6 language spec. (15,000 is just a best guess, the actual number may turn out to be significantly more or less than that. Only time and work will tell.)

Of course, for those who are primarily interested in playing or using Perl 6, as opposed to the question of "when will it be released", the primary metric is whether Rakudo implements the features needed for their primary application(s). We're gaining ground on that every day, and now that we have some of the key core features in place (list assignment, slices, working lexical vars, etc.) I expect to see a jump in our momentum. And our experience with the November wiki and mod_parrot has been that real applications find the most useful bugs to fix and push us along quickest towards running code. To me, "running code" is the real measure of success or failure here.

As you can see, we still need test developers and reviewers. New tests need to be written for under-tested areas of the spec, and we're still in the process of migrating tests from the old pugs test directory into the "official spectest" location. Generally this just a little more than moving a file -- we also want to review the tests for accuracy and put "fudge" markers in place so Rakudo's test harnesses know when to skip/todo individual tests. Fortunately, Rakudo now has far fewer instances of "we can't test that because some other unrelated feature is missing". There's also a growing pool of people who can help shepherd newcomers along through the test building process. It's not at all hard, it just takes some orientation.

Anyway, I'm really glad we've reached the 5k milestone for Rakudo, and I'm looking forward to rapidly reaching the next.

Pm

P.S.: For those who are interested in doing their own number crunching, the daily progress statistics are at http://svn.perl.org/parrot/trunk/languages/perl6/docs/spectest-progress.csv and the test summaries and graphs can be generated using the scripts in Rakudo's tools/ subdirectory. Enjoy!

Earlier in the week, fw wrote a journal post about his First Perl6 program. I was quite excited to see this, but then read a comment from educated_foo that pointed out that the Perl 5 version is actually shorter to write.

That didn't sit too well with me, because we really ought to make common things simpler, not harder. What really bugged me (about Perl 6, not about fw's post) was the following for sorting a hash by values:

    for %words.pairs.sort: { $^b.value <=> $^a.value } -> $pair {
        say $pair
    }

Sorting hashes by value is a common operation, and although I can shorten the above a little bit

    .say for %words.sort: { $^b.value <=> $^a.value };

it's still a bit long for my taste. That { $^b.value <=> $^a.value } just bugs me.

Then Moritz Lenz made a comment on #perl6 that perhaps sort should do something different with arity-1 blocks, and I then had an epiphany that led to the following pattern for sorting hashes by value:

    %hash.sort: { .value }

I like this so much, I've gone ahead and implemented it in Rakudo, even though it's not officially part of the spec. (I'm hoping it'll be adopted as such.) So now in Rakudo we have the following:

    > my %hash = { c=>5, b=>7, a=>-4, e=>9, d=>0 };
    > .say for %hash.sort: { .value }
    a       -4
    d       0
    c       5
    b       7
    e       9

    > .say for %hash.sort: { .key }
    a       -4
    b       7
    c       5
    d       0
    e       9

That seems much nicer. The general principal is that if the comparison argument to "sort" takes less than two arguments, then it's used to generate the values to be compared instead of the result of a comparison.

Of course, we aren't limited to just keys or values -- any operation we want to perform on the items being sorted will work. To sort by the magnitude of the values of the hash:

    > .say for %hash.sort: { .value.abs }
    d       0
    a       -4
    c       5
    b       7
    e       9

And of course this generalizes to more than just hashes; if @dogs contains a list of Dog objects we want to sort:

    @dogs.sort: { .name }      # sort dogs by name
    @dogs.sort: { .age }       # sort dogs by age

This works because the ".name" and ".age" methods are invoked on each of the objects in the list to determine the value to use for that object in the sort.

Or for a simplistic case-insensitive sort:

    > my @a = <Fruit CHERRY danish Apple berry BaNaNa apricot>;
    > .say for @a.sort: { .lc }
    Apple
    apricot
    BaNaNa
    berry
    CHERRY
    danish
    Fruit

Besides clarity, another big advantage of

    @a.sort: { .lc }

over

    @a.sort: { $^a.lc leg $^b.lc }

is that in the first version we compute .lc on each element only once for the entire sort, whereas in the second version it's computed once for each comparison. And since we're typically doing O(n^2) comparisons, the first version can save a lot of method or function calls.

So, that was my fun for the morning. Implementing this behavior turned out to be really easy -- in fact, I wrote the algorithm first as Perl 6 before translating it into PIR:

    multi method sort(@values: &by) {
        ...
        if &by.arity < 2 {
            my @v     = @values.map(&by);
            my @slice = (0..^@v).sort: { @v[$^a] cmp @v[$^b] };
            return @values[ @slice ];
        }
        ...
    }

The code just uses &by to compute the values (@v) to be used in the sort, does a sort on the indexes based on a comparison of those values, and uses the resulting sorted index list to return the (sorted) slice of the original list. Note that the items in the result list are themselves unchanged from the original list -- they simply have a new sequence according to the &by criteria.

Since then PerlJam++ has suggested that we should do similar things for min and max:

    my $longest_string = @strings.max( { .chars } );

This would use .chars as the criteria for determining the longest string but returns the longest string itself.

Perl 6 is very cool.

Pm

P.S.: By the way, this means that the solution to the problem in fw's original post becomes:

    my %words;
    $*IN.slurp.comb.map: { %words{$_}++ };
    .say for reverse %words.sort: { .values };

Not all of the above works in Rakudo yet (I think .comb is not yet implemented), but at least it's getting closer to what we'd really like to see here.

Yesterday I was delighted to hear that my request for a Hague Grant to work on various aspsects of Rakudo has been accepted. Jesse asked me to blog a project plan, and this post is my attempt at that. It's not going to be exhaustive and detailed everywhere, especially because some parts of this involve me working out how to do things rather than just doing them, and thus I don't know the exact details of all that has to be done yet. I'm going to break this down into what I hope to achieve over the three months this grant is scheduled for - this one and the next two.

December
This month from an implementation angle will be mostly about getting us registering symbols in the namespace at compile time and then reaping the various benefits of doing so. Thus a (probably quite complete) list of the implementation tasks will be:

• Modifications to Rakudo actions/guts so that we registering classes, roles, subset types and routines in the namespace as we are compiling. These will be stub insertions that will be replaced by the Real Thing once we have it.
• Switching us to really do "use" at compile time; last time I tried this, it broke things in pre-compiled modules, but now this needs to be figured out properly.
• Elimination of the hack that restricts us to using only type names that start with an uppercase character.
• Fix up nested classes and namespaces - this isn't really needed here, but I'd rather do it now to make sure we get the things that follow correct.

• Detection at compile-time of re-declaration of symbols and giving of errors in such situations.
• Make a proto being in scope make all other subs/methods without a plurality declarator be multis.
• Make a proto in a class turn any non-multis on roles that the class does also be multis if they were not declared that way (but see below for "only" caveat).
• Detection of "only" conflicting with "multi" and reporting of such errors.

I will also be spending some time thinking through various issues and doing some design work, to see how I'm going to do various things. Of note I want to spend time pondering:

• How dispatch is going to look. I have a lot of ideas here, many discussed with Patrick already. But we need to be in line with the metaclass interface too (which needs to make it into S12). Basically I just need to spend some time working out all of the requirements and then trying to come up with the Right Solution.
• Class construction/build things.
• Representation of parametric types, in signatures and elsewhere. We will want to be able to introspect them, enforce them, and so on.

January
In this month I plan to do two of the big changes/refactors and start building some stuff around them. The first will be changes to the dispatcher. The second will be refactoring roles to handle parameters, and the selection of what role to do based upon a multiple dispatch on the provided parameters. Since the design work this month will determine exactly what tasks will be needed, I'll instead list the things that I will expect to work by the end of the month.

• Working submethod dispatch.
• Junctions are handled in the dispatcher for both single and multiple dispatch (built-ins by this stage will be done in the Perl 6 prelude, so the special-case code that makes Junctions kinda work for operators now can be removed).
• Declaration of roles with parameters.
• Ability to specify values for those parameters when doing the role and ending up with the correct role being done, both for compile time composition and runtime mix-in.

And some nice-to-haves that can slip to February if needed will be:

• Complete filling out the various other cases of the handles trait verb.
• Test cases for writing a different dispatcher in a meta-class, to check that we've done it right (note that this means implementing knowhow, which isn't really part of this grant, but I do hope to have done this by January).

February
This month the nice-to-haves from January must be completed if they weren't already. The rest of the work will focus on parametric roles. Of note, by the end of this month, and thus the grant, I expect the following to work.

• Ability to and use parameters passed to a role when deciding to do it in the role body.
• The 'of' keyword for declaring parametric types, e.g. List of Int.

• Typed arrays and hashes implemented using parametric roles, usable and working.
• Declaring an "of" type for subroutines.

Extra Notes
There is a plan to create a Synopsis 14 that focuses on generics/type parameterization. Since I will be reviewing all of this material and will probably have some clarifications to seek/make and various things to flesh out, I plan to talk with Larry about me producing a draft of this as I am working on the grant.

So, to work I go!

one type of question about rakudo i often receive at perl meetings and on mailing lists and irc channels goes something like, "are we there yet?" sigh. as a rakudo developer, it's about the journey as much as it is about the goal. however, we still need to measure our progress to the goal, in order to manage our priorities. the vague (and sometimes pointed) questions like that above help keep me focused on the rakudo team's first big milestone, which is to produce a release package with enough functionality so that rakudo "feels like" perl 6. i expect some subsystems can be loosely classified as "alpha" status, and others "beta". but how does the development team know when we're ready for release?

qualititive measures are all we have. the perl 6 spec is large, and incomplete. the spec test suite doesn't fully cover the synopses that have been written. the tests that do cover the synopses aren't organized well enough that we can quantitatively determine spec coverage by the test suite. greater community involvement can overcome these obstacles, but that's a different topic which i hope to address soon.

rakudo's tools/test_summary.pl program runs the spec test suite, and reports a summary of results by synopsis. it lists the number of tests in the suite, the number of regression tests rakudo expects to pass, passing, failing, todo, and skipped tests. those results help us get an idea of what bits of perl 6 design are working well. that info wasn't clear enough for me, so i've made two charts out of today's data.

the first embedded chart is below, and if you can't see it, you can click your way to the percentage chart and look at it there.

the chart lists percentages based on the number of spec tests for a synopsis. since we don't know how well covered each synopsis is by the test suite, this chart only goes so far. for example, in synopsis 11, we're passing 56+% of the spec tests. however, that's only 30/53 tests. certainly, we need more than 53 tests to cover the spec for modules.

so, here's the second chart, which lists a count of tests per-synopsis. again, if you can't view it embedded here, click through to the count chart and view it there.

finally, if you need help putting names to synopsis numbers, you can view a list of the synopses at http://spec.pugscode.org.