Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.5 adds pipe operator

thephp.foundation

Post reply on HN
Print view View original

211–220 of 282 posts

Re: PHP 8.5 adds pipe operator

#211

Post by goykasi »

gbalduzzi wrote: post #179
goykasi wrote: post #159

Earlier quoted context omitted.

In the early days of PHP, it relied heavily on wrapping the underlying C libraries and preserving their naming conventions. https://news-web.php.net/php.internals/70950

And that was fine in the early days, absolutely. We are not in the early days though, and in many other aspects PHP evolved greatly.

What are the benefits? Code completion, AI agents, etc will handle it for you. No one's life is falling apart because the param ordering is more similar to C than a blog article complaining about it decade ago. Php devs have had up 30 years to learn the difference. Are C devs complaining about this?

If we want to change the param order of str/array functions for php, I think we should start with fixing the C libraries. That seems like a better starting point. The impact will certainly be more beneficial to even more developers than just php.

Re: PHP 8.5 adds pipe operator

#212

Post by rafark »

Alifatisk wrote: post #197
Mystery-Machine wrote: post #188

PHP: $result = $arr |> fn($x) => array_column($x, 'tags') // Gets an array of arrays |> fn($x) => array_merge(...$x) // Flatten into one big array |> array_unique(...) // Remove duplicates |> array_values(...) // Reindex the array. ; // Ruby: result = arr.uniq.flatten.map(&:tags) I understand this is not pipe operator, but just look at that character difference across these two languages. // This comment was my $0.02…

Can't the pipe operator be easily mimicked in Ruby thanks to its flexibility? I'm thinking of something like this: class Object def |>(fn) fn.call(self) end end which then can be in the following way: result = arr |> ->(a) { a.uniq } |> ->(a) { a.flatten } |> ->(a) { a.map(&:tags) } Or if we just created an alias for then #then method: class Object alias_method :|>, :then end then it can be used like in this way: arr…

The great thing about this pipe operator is that it accepts any callable expression. I’m writing a library to make these array and string functions more expressive.

For example, in php 8.5 you’ll be able to do:

[1,1,2,3,2] |> unique

And then define “unique” as a constant with a callback assigned to it, roughly like:

const unique = static fn(array $array) : array => array_unique($array);

Much better.

Re: PHP 8.5 adds pipe operator

#214

Post by goykasi »

Einenlum wrote: post #33
colecut wrote: post #29

Earlier quoted context omitted.

PHP string / array functions are consistent. string functions use (haystack, needle) and array functions use (needle, haystack) because that's the way the underlying C libraries also worked

They're not though. array_filter takes (arr, callback) https://www.php.net/manual/en/function.array-filter.php array_map takes (callback, arr) https://www.php.net/manual/en/function.array-map.php

array_map is variadic. It is actually (callback, ...arr)

One function works against a single element, whereas the other works against multiple. In that case, the parameter order is more meaningful. You can use array_walk if you want (arr, callback), but that only works against a single array -- similarly to array_filter.

Re: PHP 8.5 adds pipe operator

#215

Post by altairprime »

donatj wrote: post #142

I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…

It reads well to me, as someone familiar with Perl map and jq lambda. But I would syntactic sugar it rather more strongly using a new `|=>` operator implying a distributive `|>` into its now-inferred-and-silent => arguments:

    $result = $arr |> fn($x) |=>
        array_column($x, 'values'),
        array_merge(...$x),
        array_reduce($x, fn($carry, $item) => $carry + $item, 0),
        str_repeat('x', $x);
As teaching the parser to distribute `fn($x) |=> ELEM1, ELEM2` into `fn($x) => ELEM1 |> fn($x) => ELEM2 |> …` so that the user isn’t wasting time repeating it is exactly the sort of thing I love from Perl, and it’s more plainly clear what it’s doing — and in what order, without having to unwrap parens — without interfering with any successive |> blocks that might have different needs.

Of course, since I come from Perl, that lends itself well to cleaning up the array rollup in the middle using a reduce pipe, and then replacing all the words with operators to make incomprehensible gibberish but no longer needing to care about $x at all:

    $result = $arr |> $x:
        ||> 'values'
        |+ str_repeat('x', $x);
Which rolls up nicely into a one-liner that is completely comprehensible if you know that | is column, + is merge, 
    $result = $arr |> $x: ||> 'values' |+ str_repeat('x', $x);
Which reads as a nice simple sentence, since I grew up on Perl, that can be interpreted at a glance because it fits within a glance!

So. I wouldn’t necessarily implement everything I can see possible here, because Perl proved that the space of people willing to parse symbols rather than words is not the complete programmer space. But I do stand by the helpfulness of the switch-like |=> as defined above =)

Re: PHP 8.5 adds pipe operator

#216

Post by goykasi »

phplovesong wrote: post #16

The stdlib is so inconsistent this will be a nightmare. Optionally with a better language you know what order params as passed (array_map / array_filter), but in PHP its an coin toss. This feels very bolted on and not suited for the stdlib at all. PHP devs should instead FIRST focus on full unicode support (no, the mb_real_uppercase wont do), and only then focus on a new namespaced stdlib with better design.

Is array_map and array_filter the common argument? One works against a single element, whereas the other works against multiple. What would you suggest a better param order? Do you know that array_walk exists?

Re: PHP 8.5 adds pipe operator

#217

Post by guskel »

lordofgibbons wrote: post #17

Why doesn't PHP remove the horrid $ symbol for variables and the -> symbol for calling methods? I think those alone would do a lot more for its perception and adoption than adding the pipe operator.

The $ symbol gave me RSI as a dev just starting out. I will never forgive PHP for that. Such an unergonomic syntax.

Re: PHP 8.5 adds pipe operator

#218

Post by laurentlb »

rpeden wrote: post #207
sumeetdas wrote: post #138

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…

Is |> actually an operator in F#? I think it's just a regular function in the standard library but maybe I'm remembering incorrectly.

It's defined in the standard library and can be redefined by anyone.

It's usually called operator because it uses an infix notation.

Re: PHP 8.5 adds pipe operator

#219

Post by hombre_fatal »

donatj wrote: post #142

I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…

The problem with intermediate assignment is that they pollute your scope.

You might have $values and then you transform it into $b, $values2, $foo, $whatever, and your code has to be eternally vigilant that it never accidentally refers to $values or any of the intermediate variables ever again since they only existed in service to produce some downstream result.

Sometimes this is slightly better in languages that let you repeatedly shadow variables, `$values = xform1($values)`, but we can do better.

That it's hard to name intermediate values is only a symptom of the problem where many intermediate values only exist as ephemeral immediate state.

Pipeline style code is a nice general way to keep the top level clean.

Re: PHP 8.5 adds pipe operator

#220

Post by gylterud »

epolanski wrote: post #199
gylterud wrote: post #192

Earlier quoted context omitted.

What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).

And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero. Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).

There are lots of great libraries, like repa, servant, megaparsec, gloss, yampa… as well as bindings to lots of standard stuff. I consider parsing to be one of Haskell’s killer strengths and I would definitely use it to write a compiler.

There is also some popular user facing software like Pandoc, written in Haskell. And companies using it internally.

Post reply on HN