On Fri, Jan 11, 2008 at 03:59:00PM -0800, Dave Whipp wrote:
> Larry Wall wrote:
>
>> As for assignment-op forms, in the current "STD" grammar, feeds are
>> not currently even considered operators, but statement separators, so
>> there is no possibility of using them in an assignment metaoperator
>> (or any other metaoperator, for that matter).
>
> Feeds as a reduction could be an interesting concept: I think that the 
> following would allow us to create an arbitrary-length pipeline of 
> concurrent lambda processes:
>
>   my @ops = { $_**2 }, { $_+1 }, { $_/2 };
>   my @in = 1,2,3;
>
>   [==>] @in, [EMAIL PROTECTED], @out;
>
>   is_deeply @out, [1,2,5], "chain of ops".

Ignoring the * (which is obsolete and unnecessary to interpolate an
array into a list), that still won't work with the current formulation
of reduce ops.  It would mean

    1 ==> 2 ==> 3 ==> { $_**2 } ==> { $_+1 } ==> { $_/2 } ==> ()

Reduce ops aren't a macro over textual args; they operate on the values
of a normal list after normal list interpolation.  Possibly you could
get away with something like

    [==>] [EMAIL PROTECTED], @ops, [EMAIL PROTECTED];

...except that you'd probably need a recursive solution in any case,
especially since you really need to sneak a map() call in there along
with the ==>, or the individual closures won't be considered list ops.
So something a little more like this:

    sub chain ([$op, [EMAIL PROTECTED], [EMAIL PROTECTED]) {
        if @ops {
            map $op, @args ==> chain @optail;
        }
        else {
            map $op, @args;
        }
    }

    1,2,3 ==> chain @ops ==> @out;

To golf it down further you'd have to do something like

    my @listops = map { &map.assuming($^op) }, @ops;

and then maybe you could write something like:

    [==>] \(1,2,3), @listops, [EMAIL PROTECTED];

On the other hand, maybe if the target of a feed is a function with
an arity of 1 it could be automapped on behalf of the user.  Could be
a useful idiom, I suppose.  We haven't exactly defined what feeds
will do with the Captures there either, but arguably the two sides
of a normal ==> are likely to be some sort of Capture context in
any case, if you count statements as a strange sort of Capture...

And maybe just maybe the reduce metaoperator in the standard grammar
can be taught to recognize macrolike entities such as ==> and apply
the reduction syntactically rather than semantically.  But that's
kind of a long shot, I expect.

Larry

Reply via email to