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