[RFC] Pipe Operator, take 2

Hm. You're right. It used to, but it's been a very long time since
explode() allowed an empty split, apparently. I updated the example to use
str_split, which is what I'd intended to do in this case. Thanks.

Are you thinking to implode()? Anyway, you forgot to update one
explode(?) to str_split(?), and also, the first fn($v) => 'strtoupper' should be just 'strtoupper'.

I deliberately made that example extra verbose to show how ugly it can get, but I can shorten it.

About Haskell, rather than (or in addition to) the function composition
[not "concatenation"] (.), I would mention the reverse application operator
(&):
https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Function.html#v:-38-

One thing I note is that even with PFA, some examples still need an arrow
function, e.g. the PSR-7 one:

ServerRequest::fromGlobals()
    |> authenticate(?)
    |> $router->resolveAction(?)
    |> fn($request) => $request->getAttribute('action')($request)
    /* ... */;

while in Hack you would write it as:

ServerRequest::fromGlobals()
    |> authenticate($$)
    |> $router->resolveAction($$)
    |> $$->getAttribute('action')($$)
    /* ... */;

Also, quoting from
https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application
:

"""
Both approaches to the pipe operator have their advantages. The $$ based
variant allows using more than plain function calls in each pipeline step
(e.g. you could have $$->getName() as a step, something not possible with
PFA), and is also trivially free. A PFA-based optimization would entail
significant overhead relative to simple function calls, unless special
optimization for the pipe operator usage is introduced (which may not be
possible, depending on precise semantics).
"""

Could you (or Nikita) expand a bit on this (esp. the advantages of the PFA
approach / disadvantages of Hack's approach)?

Regards,

It's true PFA doesn't cover every possible RHS of pipes. In practice, I think using the piped value as an object on which to invoke a method is the only major gap. Normally in functional code you would use a lens in that case, which (if I am understanding those correctly; that's roughly at the edge of my functional understanding) is essentially a function call that wraps accessing a property or calling a method so that it feels more functional, and thus pipes cleanly.

However, piping with callables has a number of advantages.

1. The implementation is vastly simpler. It's simple enough that even I can manage it, whereas Hack-style would be more considerably implementation work.

2. I would argue it's more flexible. Once you start thinking of callables/functions in a first class way, producing functions on the fly that do what you want becomes natural, and fits better with a pipe-to-callable model. For instance, the comprehension-esque example (which I suspect will be one of the most common use cases of pipes) is far cleaner with a callable, as it can obviate any question about parameter order.

Another example I threw together last night is this proof of concept last night, which works when pipes, enums, and partials are combined. I don't think Hack-style would be capable of this, at least not as elegantly.

https://gist.github.com/Crell/e484bb27372e7bc93516331a15069f97

(That's essentially a "naked either monad".)

3. I disagree that the overhead of arbitrary callables is "significant." It's there, but at that point you're talking about optimizing function call counts, mostly on partials; unless you're using pipes for absolutely everything, go remove an SQL query or two and you'll get a bigger performance boost.

4. Far more languages have callable pipes. Hack is, as far as I am aware, entirely alone in having pipes be combined with a custom expression syntax rather than just using functions/callables. That isn't conclusive proof of anything, but it's certainly suggestive.

I'm going to be moving forward with this approach one way or another (if for point 1 if nothing else). I do believe it is the more flexible, more robust approach, and fits with the general strategy I recommend of small, targeted changes that combine with other small, targeted changes to offer more functionality than either of them alone. That's exactly what we're doing here.

--Larry Garfield

2021-06-28 22:12 GMT+02:00, Larry Garfield larry@garfieldtech.com:

Usage (ignoring the pesky undefined constant warnings ><):

Unfortunately, you can't ignore those warnings; not least because
they're fatal errors in PHP 8, as they frankly should have been in PHP 3.

You can use our current ugly callable syntax (strings and two-element
arrays); you can tackle the complexity of unifying functions with
constants, and methods with properties (as Levi explained in the other
thread); or you can add a dedicated callable syntax, which the PFA
proposal gets us with bells on.

Regards,

I think that's a pretty good summary. There's nothing that pipes or
partials do that you couldn't emulate in user-space today (really, since 5.3
is you really wanted to). The emulation is just butt-ugly and slower, which
is why most people don't do it except in very specific cases or if they have
a user-space library available that makes it slightly less butt-ugly.

The purpose of PFA and pipes (and short functions, and auto-capture
closures, and basically everything else I've been talking about all year) is
to make those things prettier and as fast as reasonable, which makes using
those techniques more natural. Once you start down that path, though,
there's really no usable solution before you get down as far as... PFA and
Pipes in their current form.

--Larry Garfield

The challenge is to write something that's pretty enough to be
considered idiomatic. :) The pipe operator in OCaml is defined by one
line:

let (|>) v f = f v

It wasn't always part of core, but eventually it was so common, it got
included by default. Same could happen with a pipe() function in PHP,
without the pipe operator, or that the function becomes so common, a
new keyword is added instead: pipe. But it could probably not happen
with a Pipe object requiring you to write ->pipe() at every step -
it's too much ceremony and boilerplate.

By the way, that's alternative 5) New keyword pipe to make the
warning about constants shut up in a certain scope. Plus some other
magic to allow nice chaining. ^^

Olle

Sorry for hijacking the thread, but are there no other alternatives,
really? Just brainstorming:

1. Setting to silence the warning.

Just to reiterate: in PHP 8.0, an undefined constant is not a warning,
it's an error. My apologies to code golfers: you can no longer save two
bytes by leaving the quote marks off your strings.

However, that's not really the problem. The problem is when there is a
constant with that name:

const foo='strtoupper';
function foo($x) { return 'test'; }
$input = ['hello', 'world'];
var_dump( array_map(foo, $input) ); // this runs strtoupper(), not foo()

This doesn't work even in old versions of PHP where undefined constants
fell back to strings.

Even in cases where this trick did work in older versions of PHP, it was
just a variant of option one, "use our current ugly callable syntax" -
it saved you those two bytes, but it didn't actually provide you a
function reference.

Unifying the constant and function name tables would not be to just a
different way of writing strings, it would let array_map(foo, $input)
actually check that function foo existed, and represent callables as a
proper type. Meanwhile, to let array_map($object->foo, $input) do the
same thing (instead of the current [$object, 'foo'] syntax) you also
need to unify the method and property tables, which is probably even harder.

2. Setting to silence the warning IF and only if argument expects a
   callable, like in array_map (won't work with a pipe() function,
   though, since pipe() would take any number of arguments and that can't
   be typed)

In the general case, this is a non-starter: the parameters need to be
parsed from the source code before function definitions are even known.
You could special-case a handful of built-in functions, but that would
be extremely clunky.

3. Silence the warning if you type-case explicitly, like in
   pipe($start, (callable) htmlentities);. Another alternative is
   (fn) as a type-cast. Not much better than pipe($start, htmlentities(?)), I guess. Just different style.

This falls into my third option: "add a dedicated callable syntax". That
could be something that looks a bit like PFA but isn't, like Nikita's
RFC; or something that looks a bit like a type cast; or any number of
other ideas which have been brainstormed for about as long as I've been
programming PHP.

4. Silence the warning ONLY when it's the right-hand argument to pipe
   operator, like $start |> str_len.

Re-wording this as "interpret the unquoted word as a function reference
rather than a constant when...", this one is at least plausible. In
practice, though, a lot of functions don't take only one parameter, so
the previous pipe proposal included a placeholder for which argument you
wanted to "pipe into". At which point you don't need to special case
keywords, because you can just write this:

$start |> str_len($$)

Regards,

--
Rowan Tommins
[IMSoP]

Just to clarify,

I said it didn't look like it could be a pure AST implementation, and that
it looks like you may need one additional instruction.

It does look that way to me - if only to throw a sensible error
specifically for pipes but also because it makes the imposition of specific
behaviour for pipes a little easier, but it doesn't make it a super
complicated thing.

I also said I didn't know what the right answer was with regard to refs. I
still don't, although I lean towards blocking them at the moment having
spent a little more time looking at it.

I don't really think we've had long enough to have this conversation
properly.

Cheers
Joe

Hi folks. Me again.

A year ago, I posted an RFC for a pipe operator, |>, aka function
concatenation. At the time, the main thrust of the feedback was
"cool,
like, but we need partial function application first so that the
syntax
for callables isn't so crappy."

The PFA RFC is winding down now and is looking quite good, so it's
time
to revisit pipes.

https://wiki.php.net/rfc/pipe-operator-v2

Nothing radical has changed in the proposal since last year. I have
updated it against the latest master. I also updated the RFC to use
more examples that assume PFA, as the result is legit much nicer. i
also tested it locally with a combined partials-and-pipes branch to
make sure they play nicely together, and they do. (Yay!) Assuming
PFA
passes I will include those tests in the pipes branch before this
one
goes to a vote.

Hi again.

With PFA being declined, I've again reworked the Pipes RFC.

1. It now does not use PFA in any examples, but it does use Nikita's
   first-class-callables RFC that looks like it's going to pass easily.

2. With major hand-holding from Levi Morrison and Joe Watkins, the
   implementation has shifted a bit. It now evaluates left-to-right,
   always, whereas the previous version evaluated right-to-left. That
   is,
   instead of $a |> $b |> $c desugaring into $c($b($a)), it now becomes
   effectively $tmp = $a; $tmp = $b($tmp); $tmp = $c($tmp); That matters
   if $b or $c are function calls that return a callable, as they are
   then
   only called when the pipeline gets to that part of the expression.
   (If
   all the functions involved are pure functions, then it doesn't make a
   difference in practice.)

3. I included references to several existing PHP libraries that
   implement similar logic, in mostly complex and ugly ways.

4. Of note, Brent posted a Twitter poll last week about pipes, and the
   response was overwhelmingly in favor.
   (https://twitter.com/brendt_gd/status/1408271132650885123) Naturally
   a
   Twitter poll is extremely unscientific, but I think between the
   existing libraries and the response there the answer to the question
   "is there actually a demand for this feature?" is unquestionably yes.

5. Examples have been reworked to be a bit prettier.

6. Added another language reference that has a pipe operator that
   works
   basically like described here. (OCaml)

I am planning to take this version of the RFC to a vote on Monday or
Tuesday, as Tuesday is the last day possible to start a vote for 8.1
features.

--Larry Garfield

Based on feedback on the PR, I've updated the RFC to forbid functions
that pass or return by reference. They're not really useful in pipes
at all, and were only supported before because the implementation
happened to allow it.

The PR hasn't been updated for that yet, but I figure that's easy
enough to update post-vote if it passes.

Sorry for the noise, but after some discussion with Joe it looks like
blocking references in pipes is actually much harder than it sounded like,
and would require a completely opcode based implementation rather than the
completely AST-based implementation. References on pipes are not really
useful but in practice they don't hurt anything. I've instead added more
tests to validate that they behave "as expected" and noted that in the RFC
instead.

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php