Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

2010-02-18 Thread Mark J. Reed
On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak
perl6-bugs-follo...@perl.org wrote:
  my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to 
 TimToady


That's 4 ... ^5, right?  If so, I don't see how you get that.  I'd
expect (4,0,1,2,3,4), without the countdown between 4 and 0.


-- 
Mark J. Reed markjr...@gmail.com


Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

2010-02-18 Thread Larry Wall
On Thu, Feb 18, 2010 at 12:45:23PM -0500, Mark J. Reed wrote:
: On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak
: perl6-bugs-follo...@perl.org wrote:
:   my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to 
TimToady
: 
: 
: That's 4 ... ^5, right?  If so, I don't see how you get that.  I'd
: expect (4,0,1,2,3,4), without the countdown between 4 and 0.

Unlike the .. operator, the ... operator does autoreversing.  Also, it's
a list infix operator, which means it takes a list on either side.
Since ^5 can produce a list, what ... sees is, in the abstract:

4 ... 0, 1, 2, 3, 4

In reality, the right list is lazy, so ... has to .get the first value
from the iterator on the RHS and examine what it gets back.  If that
is a limit value, it tells ... how far and in what direction to keep
going with the left side.  So effectively the ... above really only
needs to know

4 ... 0

before it decides how to proceed.

Sometimes the ... has to pull two values off the RHS.  If the first
value is a * or a closure, then the first argument says how to derive
new values on the left, and the 2nd value on the right gives the limit.
To be clearer, or at least different, the programmer could write:

4, 3 ... *, ^5

This question arises, of course, because ... doesn't currently support a ...^
notation as ..^ provides for ranges, so 0...^5 doesn't do what you might
expect.  We might well fix that, or at least detect it and warn.  But it
does seem a bit odd to have to put your own epsilon:

0 ... *, 5-훜

so maybe

0 ...^ *, 5

could be forced to mean that.  Might be an argument for moving the
increment to the other side:

0, *+1 ...^ 5

We'd have to think about the ramifications of that though, which are not
all pretty.  In particular, we still need the * on the right for

1,2,4 ... *

since a missing term:

1,2,4,* ...

would be bad to parse, since we wouldn't know whether to expect a term
or an infix.  Maybe, though, that's confusing two different uses of *,
since this makes perfect sense:

1,2,4,* ... *

and admits things like

1,1,[+] ... *  # fib

And if we see

1,2,4 ... *

we can assume it means

1,2,4,* ... *

Likewise

1,2,4 ... 256

would really mean

1,2,4,* ... 256

Maybe I like it.

Larry