Fw: right-to-left pipelines
Luke Palmer
Note: this is back on-list.
> From: "Me" <m...@self-reference.com>
> Date: Mon, 9 Dec 2002 01:27:55 -0600
>
> [regarding -> as a left-to-right pipe-like operator]
>
> Please do. As in, please point out on list that
> '->' is already established as a left-to-right
> flow/assignment operator so why not consider
> extending/modifying it to be more general? ;>
I would, except for '->' isn't (in my mind) "a left-to-right
flow/assignment operator." It's a unary operator, synonymous with
"sub" without parens required around the argument list.
Luke
Me
>
> flow/assignment operator." It's a unary
> operator, synonymous with "sub" without
> parens required around the argument list.
You seem to be forgetting:
given $foo -> $_
and cousins.
--
ralph
Luke Palmer
> Date: Mon, 9 Dec 2002 02:12:41 -0600
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Nope, I'm not.
given $foo -> $_ { ... }
given $foo { ... }
given $foo sub { ... }
Are all equivalent (if sub topicalizes its first parameter).
Thus, the signature of given, for, et cetera, is:
sub given($var, &block) { ... } # Without the comma, somehow.
Luke
Me
> > > flow/assignment operator." It's a unary
> > > operator, synonymous with "sub" without
> > > parens required around the argument list.
> >
>
> Are all equivalent (if sub topicalizes its
> first parameter).
Oh. Now I understand C<->> rather differently!
The left-to-right flow/assignment viewpoint
had worked for me as an (incorrect) way to
interpret C<->> when used with C<for> et al.
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.
--
ralph
Michael Lazzaro
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.)
Michael Lazzaro
On Monday, December 9, 2002, at 10:37 AM, Michael Lazzaro wrote:
> @source >> grep { /foo/ } >> @out; # [5] pure L-to-R
Of course, we *could* define piping such that the C<grep> is not
necessary:
@source >> /foo/ >> @out;
... by saying that a regex or closure in a pipe DWYM. Similar to the
way we have the "do-everything" C<given>.
:-)
MikeL
Smylers
> Of course, we *could* define piping such that the C<grep> is not
> necessary:
>
> @source >> /foo/ >> @out;
>
> ... by saying that a regex or closure in a pipe DWYM.
I think I'm against that because it makes it hard for somebody who sees
that in code for the first time to look something up in docs to discover
what it does. With the word "grep" in there, they've got something they
can search for.
> Similar to the way we have the "do-everything" C<given>.
Except that "given" is also a word that can be searched for. Yes
there's a lot of dwimery in using it, but that can all be hung off the
C<given> docs.
Hanging magic behaviour off pipelines could only be documented under
C< >> > (or whatever's chosen), and when an unfamiliar code snippet
contains a bunch of punctuation symbols it often isn't at all obvious
which bit the docs will help. And even once it's been worked out,
non-words can be hard to search for.
Smylers
Me
> as a placeholder.
I like it as the real thing too. It stands
out better in a line, among other advantages.
> @source >> @out; # 'map' or 'assignment'-like
> @source >> grep { /foo/ } >> @out; # object-method-like
Yes, several issues arise.
First, I don't think it's necessary to allow
a variable (or variables) to be anywhere other
than the front of a chain.
@var = [var|code] >> code >> code;
Second, it would be nice to allow a pipeline
element to pass the LHS, and invoke the RHS,
in one of two ways: iterated or not. If this
were to be done implicitly, perl (and humans)
would have to parse the whole pipeline from
the right to left, defeating the point of a
l2r pipeline syntax in the first place. So,
iteration would need to be invoked explicitly.
Perhaps something like:
@var = for @source >> /foo/ >> sort;
--
ralph
Luke Palmer
> Date: Mon, 9 Dec 2002 17:12:13 -0600
>
> First, I don't think it's necessary to allow
> a variable (or variables) to be anywhere other
> than the front of a chain.
>
> @var = [var|code] >> code >> code;
Agreed.
> Second, it would be nice to allow a pipeline
> element to pass the LHS, and invoke the RHS,
> in one of two ways: iterated or not. If this
> were to be done implicitly, perl (and humans)
> would have to parse the whole pipeline from
> the right to left, defeating the point of a
> l2r pipeline syntax in the first place. So,
> iteration would need to be invoked explicitly.
> Perhaps something like:
>
> @var = for @source >> /foo/ >> sort;
There is: vectorize it. The result is surprisingly ugly:
@var = @source ≫>>≪ reverse >> sort;
(The regex case wouldn't work under I<my> idea of this operator, as
it's not a function). C<map> comes to the rescue:
@var = @source >> map { reverse } >> sort;
Luke