take-ing to-be-modified variables
When take is called on a variable that is later modified, is the Capture returned by the enclosing gather supposed to reflect the change or not? I know that Captures are the Perl 6 equivalent of references, but it seems natural to expect the contents to be copied by value at some point prior to the variables being modified. As an example, what is the output of the below program supposed to be? On Rakudo (which doesn't seem to support multidimensional captures properly), it's [20, 21, 22, 20, 21, 22, 20, 21, 22, 20, 21, 22] instead of the desired [[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12, 13, 14], [15, 16, 17, 18, 19]]. I could get around this problem by copying the variable before take-ing it, e.g., writing take [ @things ] instead of take @things; likewise, when writing similar code that takes string variables, copying could be performed by enclosing the variable in double quotes. However, for more complex datatypes, is there an easier (i.e., shorter) copying mechanism than assigning the value to a new variable that is scoped to the current block? Is this even necessary, i.e., is the observed behavior just a bug in Rakudo, or is that too much to hope for? #!/usr/bin/env perl6 use v6; my @stuff = gather { my @things; for ^23 { @things.push: $_; if @things == 5 { take @things; @things = (); } } } say @stuff.perl; __END__ -- Minimiscience
Re: How to speed up a grammar
On Jun 6, 2009, at 10:32 AM, Richard Hainsworth wrote: rule element { '' name attribute* [ | '/' | '' element* '/' $name '' ] } This is just a wild, uneducated, possibly delusional guess, but I don't think that vertical bar before the '/' should be there. I think it might be causing the grammar engine to check whether it can omit the ending of each tag and attach it to the enclosing tag instead, which it can't confirm without examining the whole file at least once for each tag. -- Minimiscience
Re: RPN calculator in Perl 6
[I just realized I sent this directly to Daniel rather than to the list, so for the benefit of onlookers...] On Jun 6, 2009, at 1:51 PM, Daniel Carrera wrote: Daniel Ruoso wrote: Yes... that's what wasn't implemented... But now it is ;) http://sial.org/pbot/37085 Close, but... % perl6 rpn.pl 5 4 + 3 / 5 3 - * -6 That should be a positive 6. I think I see the problem (assuming it hasn't already been pointed out off-list). The infix:rpn(@a, $op where ...) operators call .shift on the arrays to get the operands, yet the infix:rpn(... , $b where / Num/) operators place the numbers on the *end* of the stack, where the next reverse-polish operator should read them from. Thus, when the '-' is processed, the stack is 3 5 3, where the first three is the result of 5 4 + 3 /, and the first two numbers are shifted off for subtraction rather than the last two. In order to fix this, either change the first two infix:rpn() functions so that they place new numbers at the *beginning* of the array, or else change each occurrence of my $ls = @a.shift; my $rs = @a.shift; To: my $rs = @a.pop; my $ls = @a.pop; (Note that, in addition to the use of .pop, $rs is now acquired before $ls.) At least, I think that's how it works. -- Minimiscience