On Monday, December 9, 2002, at 01:19 AM, Me wrote:
I like this so much it's not even funny. (But I'd suggest using >> instead of -> for now, as a placeholder. To avoid confusing people as to the true meaning of ->.)So, I guess I'm suggesting a binary C<->> that really is a left-to-right flow/assignment op so that:@data -> grep { $_ > 0 } -> sort { $^b <=> $^a } -> part [/foo/, /bar/] -> @foo, @bar; does what you'd expect.
Amongst our weaponry:
@out = grep { /foo/ } @source; # [0] perl5 (obselete)
@out = @source.grep { /foo/ }; # [1] object-based
@source.grep { /foo/ } >> @out; # [2] L-to-R
@out = grep @source: { /foo/ }; # [3] indirect object
grep @source: { /foo/ } >> @out; # [4] L-to-R
@source >> grep { /foo/ } >> @out; # [5] pure L-to-R
But oops, I think. The only way [5] could work is if both of the following do the right thing:
@source >> @out; # 'map' or 'assignment'-like
@source >> grep { /foo/ } >> @out; # object-method-like
Which leads to the question: Would a >> operator, be the L-to-R inverse of '=', or of ':=', or another way to say '.', or a variant of C<map>, or of C<given>, or ???. Could we reasonably parse more than one meaning?
MikeL
(Or we could disallow [5], and use [2] instead. But it chains slightly less politely.)