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
