On Monday, December 9, 2002, at 01:19  AM, Me wrote:
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.
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 ->.)

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.)

Reply via email to