Pipe Operator v2

I mean, maybe it's just me, because I'm familiar with the cascade operator
from other languages - but it seems simpler, more intuitive, easier to pick
up, and appears to solve most of the same problems? If so, perhaps it would
be right to consider the cascade operator as an alternative to this feature.

They're not really the same thing at all; in some ways they're actually
opposites. The cascade operator is a way of discarding the result of an
object-oriented expression, and reusing the same context repeatedly. The
pipe operator is a way of capturing the result of a procedural
expression, and passing it forward to the next expression.

It seems to me, the main difference between the pipe operator and a cascade
operator, is the anonymous context variable $$ created by the pipe operator

• I think, partially, this is what makes those expression hard to read; the
  context changes (or does it?) along the way, but the (nameless) symbol used
  to reference those objects, in the same expression, are identical.

Yes, the $$ means "result of last expression". In essence, it's a bit
like Perl's $_ variable, except that it doesn't exist outside the pipe
syntax. It has to exist to say where you're going to use that result in
the next expression.

In the cascade operator, you don't need a notation for it, because the
context is always on the left of the operator:

$foo
->>setBar(1) // context is $foo->...
->>setBar(2); // context is still $foo->...

But again, this isn't the primary difference between the operators; the
difference is that one is a way of discarding results, the other is a
way of carrying results forward.

Regards,

--
Rowan Collins
[IMSoP]

FWIW, I've read the manual page for the Hack page, and the RFC, a couple of
times now, and I simply don't understand it.

Perhaps the documentation needs clarifying then.

Are most PHP developers going to understand this feature, the meaning of
$$, and when/how to use this?

Yes. PHP developers are excellent at Google and StackOverflow.

Are they going to be able to read code written in this way?

Yes.

To your knowledge, are there any other languages where this feature is
found, or is it another one of those exotic features currently found in
Hack and nowhere else? (I know a bunch of languages, and this feature
doesn't ring any bells.)

Elixir, F#, Swift (via library extension), ISTR a few others when I
was researching a few months ago, but can't recall them offhand.

How does this feature compare with the cascade operator more commonly found
in other languages?

To turn your previous question around, what languages?

I see them complementing one another, serving different goals and
solving different problems. I suppose you could ask how this compares
with short ternaries, coalesce, or bitwise xor, and the question will
make as much sense.

I mean, maybe it's just me, because I'm familiar with the cascade operator
from other languages - but it seems simpler, more intuitive, easier to pick
up, and appears to solve most of the same problems? If so, perhaps it would
be right to consider the cascade operator as an alternative to this feature.

I would rather consider them both since they solve different problems
in different ways.

I know that Hack may be closer in nature to PHP than some other languages,
but if someone is familiar with both, likely they're not coming from Hack
and moving to PHP, they're likely moving from PHP to Hack, so language
similarity might not be the best argument for referencing Hack on this
point, as opposed to referencing other languages...

Fair point, I'll add mentioned of the above languages to the RFC.

It seems to me, the main difference between the pipe operator and a cascade
operator, is the anonymous context variable $$ created by the pipe operator

• I think, partially, this is what makes those expression hard to read; the
  context changes (or does it?) along the way, but the (nameless) symbol used
  to reference those objects, in the same expression, are identical.

It's also what makes the cascade operator unable to solve all the
problems which the pipe operator is capable of solving. Cascade
applies to a very narrow band of instance method calls. Pipe applies
best to static methods and procedural functions (which some
applicability to methods). The flexibility of being able to place
that lhs element in an arbitrary location is what makes it powerful.

Rather than writing extremely long expressions, as demonstrated in the RFC,
I think, personally, if this feature were introduced, I'd lean more on
intermediary variables, with names, that clarify the meaning - referencing
a bunch of intermediaries with a nameless variable doesn't help readability
at all, in my opinion.

The RFC states why this may not be a preferred course. How do we
know, at a glance, that these well named intermediates are/aren't used
later in the scope? What happens to destructor ordering when the
variable lives till the end of the function? How does this impact
optimization potential?

In contrast, I have no issue reading expressions with the cascade operator;
again, maybe that's just because I'm familiar with that operator from other
languages, but I don't think the nameless $$ variable helps readability or
understanding.

You keep acting as if pipe vs cascade is even a competition. It's
not. They're different solutions to different problems which require
different approaches.

-Sara

It's possible to use the tilde ~ easyly on keyboards?
For on BR/ABNT2 is easy. So maybe use ~> as operator could be fine,
instead of the triangle |>, and linear sounds good too, like:
$string~>escape($$)~>dump($$);

It's used currently on PHP for a bitwise operation (not), so I think
that the usage are not a problem in general.
Too will not have a conflict, because ~> no make any sense to PHP today.

2016-07-22 2:52 GMT-03:00 Sara Golemon pollita@php.net:

Are you picturing the return statement returning from the current
function? Or "returning" from the current pipe chain?

I think you mean the former, in which case I'd ask how that'd better/worse
than:

return foo() |> bar($$);

I do indeed mean returning from the current function. I went into more
detail (perhaps too much!) on the previous thread, but the basic premise is
the pipe operator gives you code that reads left to right. Adding an element
where you have to jump back to the beginning of the expression feels like it
defeats that.

Ah! I understand your point now. Indeed, in terms of code-scan,
there's something of a whiplash effect going on. Now I understand the
motivation behind $> assignment and/or using a terminal like return $$ at the end.

Adding in support for some terminals (like return) could make sense,
it's an exception to a rule, but it's a reasonable looking one (at
first glance, anyway).

The assign to var at the end however, is something I'd rather handle
with the following:

foo() |> bar($$) |> $baz = qux($$);

Which is both legal with the syntax as-is, and entirely readable
without adding an extra operator.

-Sara

--

--
David Rodrigues

Ah! I understand your point now. Indeed, in terms of code-scan,
there's something of a whiplash effect going on. Now I understand the
motivation behind $> assignment and/or using a terminal like return $$ at the end.

Adding in support for some terminals (like return) could make sense,
it's an exception to a rule, but it's a reasonable looking one (at
first glance, anyway).

Glad it makes sense. :) I realise "return $$" would have to have some
special handling, but it would feel more natural to me. I guess the only
concern is what happens when a pipeline has a return terminal and is
used in expression context:

$foo = bar() |> baz($$) |> return $$;
// theoretically translates to this invalid PHP:
$foo = return baz(bar());

I'm not sure how easily the compiler would be able to pick up that
that's an illegal construction.

I was going to say that "yield" would be worth considering at the same
time, but presumably that's already legal, because yield can appear as
an expression (to receive variables sent into a co-routine).

It's a shame neither "echo" nor "print" is useful for getting $$ out to
screen and leaving it unchanged (echo doesn't work in expression context
at all; print doesn't have a useful return value).

The assign to var at the end however, is something I'd rather handle
with the following:

foo() |> bar($$) |> $baz = qux($$);

Which is both legal with the syntax as-is, and entirely readable
without adding an extra operator.

Yes, on reflection I think "|> $foo = $$" is probably easier to follow
than extra syntax. I quite like the idea of a whole language where data
always flows left-to-right, but we're used to that being what assignment
looks like.

It might be worth coming up with some examples to add to the RFC where
$$ is used in an expression other than a function call, because I wasn't
entirely sure when I read it if that was even allowed. It might also
clear up some of the confusion around this being anything to do with OO.

Off the top of my head, how about some maths:

$foo * $bar
|> 2 ** $$
|> sin($$ + 1)
|> $$ / 20
|> $result = $$;

Compiles to:

$result = sin((2 ** ($foo * $bar)) + 1) / 20;

Or:

$temp = $foo * $bar;
$temp = 2 ** $temp;
$temp = sin($temp + 1);
$result = $temp / 20;

Regards,

--
Rowan Collins
[IMSoP]

On mobile, sorry for top posting.

Multiple $$ means the resulting closure will accept multple arguments.

I'm definitely against dropping the ($$) on the right hand side because it
would use non standard symbol lookup rules.

$x = trim;

This normally will look up a constant, and then apply barewords if it
doesn't exist. Let's not go down the road of special casing things.

Le 19/01/2017 à 22:53, Levi Morrison a écrit :

On Thu, Jan 19, 2017 at 11:12 AM, François Laupretre flaupretre@free.fr
wrote:

Le 19/01/2017 à 13:54, Levi Morrison a écrit :

The |> symbol would be the piping operator with these semantics:
1. Evaluate the left-hand side.
2. Evaluate the right-hand side. Assert that the result is
callable.
3. Pass the result from 1. as the single argument to 2.

May I suggest extending your 3rd rule to : when the right hand side has
the
form of a function call, insert the result from 1. as first argument of

This way, right hand side may specify additional arguments

If we only had |> this may be good but since we are also proposing
$$ then this renders your suggestion unnecessary:

 $string |> trim($$)

Would work just fine with no performance overhead.

Additionally, you could write:

 $input |> array_map($fn, $$)

Or:

 $input |> array_filter($$, $fn)

Basically, $$ gives the flexibility of passing additional arguments
and keeps |> simple. No need for additional rules for |>.

Right, I just suggest to make the '$$' optional when used as first arg of
a rhs call. Except complex cases like array_xx() functions which will
generally require an explicit '$$', most cases will feature a '$$' as first
arg of a function call. This may be considered as better because more
explicit, but I think the case is prominent enough to justify this
'shortcut'.

Another question: Will you accept several occurences of '$$' in a RHS ?

Last, a cosmetic suggestion : replace '$$' with '$<' (more explicit as
'input data', imo).

Regards

François

Le 19/01/2017 à 22:53, Levi Morrison a écrit :

On Thu, Jan 19, 2017 at 11:12 AM, François Laupretre flaupretre@free.fr
wrote:

Le 19/01/2017 à 13:54, Levi Morrison a écrit :

The |> symbol would be the piping operator with these semantics:
1. Evaluate the left-hand side.
2. Evaluate the right-hand side. Assert that the result is
callable.
3. Pass the result from 1. as the single argument to 2.

May I suggest extending your 3rd rule to : when the right hand side has
the
form of a function call, insert the result from 1. as first argument of

This way, right hand side may specify additional arguments

If we only had |> this may be good but since we are also proposing
$$ then this renders your suggestion unnecessary:

 $string |> trim($$)

Would work just fine with no performance overhead.

Additionally, you could write:

 $input |> array_map($fn, $$)

Or:

 $input |> array_filter($$, $fn)

Basically, $$ gives the flexibility of passing additional arguments
and keeps |> simple. No need for additional rules for |>.

Right, I just suggest to make the '$$' optional when used as first arg of a
rhs call. Except complex cases like array_xx() functions which will
generally require an explicit '$$', most cases will feature a '$$' as first
arg of a function call. This may be considered as better because more
explicit, but I think the case is prominent enough to justify this
'shortcut'.

Another question: Will you accept several occurences of '$$' in a RHS ?

Last, a cosmetic suggestion : replace '$$' with '$<' (more explicit as
'input data', imo).

Regards

François

On Thu, Jan 19, 2017 at 4:08 PM, Rowan Collins rowan.collins@gmail.com
wrote:

When you say assert the right hand side is callable, does that mean to
call an object method, you would do [$obj, 'method']? What about
functions,
is it just the name like $str |> trim, or is it $str |> trim()?

This is a good point. The difference between the pipe operator as proposed
by Sara and the combination of two separate operators is that in Sara's
proposal you'd always write this:

$str |> trim($$)

But in Levi's proposal as I understand it, the right-hand side is not
syntax, it's just constrained to be callable, so the simpler (but rather
ugly) form would be:

$str |> 'trim'

See I don't like that at all, I hate having to put functions/methods in
strings, as find usages and refactor tools generally don't find the
strings. But sometimes I have to yield my preference to those who outrank
me (aka those with voting power)

While this would be permitted:

$str |> 'trim'

So would:

$str |> trim($$)

I empathize that you don't like string-name callables (I really don't
like them either) but this RFC helps avoid the string if you want to.
Consider

// without my proposal:
array_map('trim', $input)

// with it:
array_map(trim($$), $input)

Which makes a bigger difference for namespaced functions:

// without my proposal:
array_map('namespaced\func\map', $input)

// with it (assuming you are in the correct namespace or
// did `use function namespaced\func\map`:
array_map(map($$), $input)

So to summarize, the right-hand-side of |> being callable doesn't
mean you "have to" put it in a string; you can pair it with $$ to
avoid that.