Apologies and Vector Again

In my last post I griped a bit about the lack of progress on several of the issues that have been bothering me. Well, it turns out there is a sad explanation for why things have been slow. I came into the Perl 6 sphere after the previous cancer bout referred to here, so this was a complete surprise for me. Of course Patrick's wife's health is vastly more important than getting my toy program working. I wish them both all the best.

In the meanwhile, while that stuff hasn't been fixed, there's apparently been a huge wave of progress with the metaops in the last week -- enough so that I thought it might be worth trying Vector again. And, well... It blew up compiling Vector.pm with a pretty obscure error message. Pretty easy to guess the source of the problem, though:

> my @a = 1..3; my @b = 3..5; say @a >>*<< @b
3815
> my @a = 1..3; my @b = 3..5; say @a »*« @b
Confused at line 1, near "say @a \x{c2}\x{bb}*"

So Texas hyper-ops work, but the proper ones do not. Well, that's an easy enough change.

Hmmm... next issue: is also is history. It's augment now. That's easy enough. And then you get Can't augment class Vector without 'use MONKEY_TYPING'. Which is also easy to fix.

Next error, though is

error:imcc:syntax error, unexpected '\n'
 in file 'EVAL_5' line 58
Contextual $*PKGDECL not found

Ummm... I've got nothing. Any one have an idea what this might mean?

Progress and Congress

So, it's was interesting to see the relative receptions of my last two posts. Laziness, the Catch caused a massive flurry on discussion on #perl6, and eventual plans for how to overhaul Perl 6 and Rakudo to deal with it. As far as I know, though, there's been no development in this area in Rakudo, so the scary bug is still very much present.

On the other hand, the Lazy Sieve of Eratosthenes gather / take bug is generally acknowledged, but doesn't have any momentum towards a patch at all, as far as I can see from #perl6.

On the gripping hand, at least a few of the file operators (another issue with the E03 update) now work, thanks to lue++.

It does seem like a fantastic amount of progress is being made on Rakudo at the moment. I just hope these issues get addressed before Rakudo Star.

Lazy Sieve of Eratosthenes, sidetracked

A Hacker News article about the Sieve of Eratosthenes got me thinking about how to do a lazy, infinite Sieve in Perl 6. (I didn't read the whole article, because I wanted to produce my own implementation first!) Unfortunately, my attempt to do so turned up what seems to be a very major bug lurking in Rakudo's gather / take.

Basically, my notion was this. The Sieve essentially consists of crossing off multiples from a list each time you find a new prime. So what if instead of taking the list to be a fixed limited, fixed array of numbers, you made it an actual infinite lazy list? All you need is a function which, given two infinite lists of numbers, takes the least element at the front of the lists and returns that. Then you when find a new prime, you take your existing list and use that function to merge in the list of multiples of the new prime.

So I started to code this up, and instantly ran into weirdness.

sub sorted-infinite-sequence-merge(Iterator $a-iterator, Iterator $b-iterator)
{
    my $a = $a-iterator.get;
    my $b = $b-iterator.get;

    gather loop {
        my $next = $a min $b;
        # say "$a, $b, $next";
        take $next;
        $a = $a-iterator.get if $a == $next;
        $b = $b-iterator.get if $b == $next;
    }
}

sorted-infinite-sequence-merge((1..100).iterator.map({$_*3}), (1..100).iterator.map({$_*4})).batch(20).perl.say;
sorted-infinite-sequence-merge((3, 6 ... *), (4, 8 ... *)).batch(20).perl.say

That code generates the following two lists:

(3, 4, 6, 8, 9, 12, 15, 16, 18, 20, 21, 24, 27, 28, 30, 32, 33, 36, 39, 40)
(4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68, 72, 76, 80)

As you can see, the first list is clearly correct. The second list (which calls the same merge function, but using source lists generated via series instead of Range) is clearly incorrect. I believe this must represent some sort of gather/take bug triggered by nested gather/take operations.

Help?