On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> Though it's awfully tempting to fill in the holes in the periodic table:
>
> ($a, $b, $c) = @foo *<< 3;
>
> And then just say all the corresponding unaries default to 1 (or the arity
> of the left):
>
> $bit = +<< $number; # $number +<< 1
> $graph = ~<< $string; # chip()/chimp()
> $whether = ?<< $boolean; # presumably clears $boolean
> $elem = *<< $iterator; # shift $iterator
Well, that's interesting.
> I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries,
> if we add 'em at all. I do think
>
> foo( @bar *<< 3 )
> foo( @bar *>> 3 )
Hrm... if you're thinking of going that way, I'd rather have a
lazy-assignment/destructive-pipe operator of some sort:
($a,$b) <== [EMAIL PROTECTED]; # splice(@bar, 0, 2)
($a, $b) ==> [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b)
[EMAIL PROTECTED] ==> ($a, $b); # splice(@bar, -2)
[EMAIL PROTECTED] <== ($a, $b); # splice(@bar, @bar, 0, $a, $b);
Of course, with something indicating the desire to modify the array. I
don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an
idea.
I'd want some way of telling the array to lazily add/remove elements
as part of the pipe operator, which would make:
foo <== [EMAIL PROTECTED]; # REMOVE however many elements from the front of
@bar
as foo() wants
However, this would lead to me thinking about this sequence:
[EMAIL PROTECTED] ==> map ==> grep ==> @whatever;
as:
while pop @this { ... unshift @that, $_ }
Which would be interesting (bad) for performance
Ashley
