take-ing to-be-modified variables

2009-07-21 Thread Minimiscience
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

2009-06-06 Thread Minimiscience

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

2009-06-06 Thread Minimiscience
[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