pipes, scalar objects and on?

So. Let's get back to pipelines.

I wrote this email because I was manipulating a robots meta tag string:

$robots_array = explode(', ', $robots_string);
$robots_array = array_diff($robots_array, $remove);
$robots_string = implode(', ', $robots_array);

Very pipeline-ish.

You could write a userspace pipeline
https://gist.github.com/chx/6638aba76d8b414ffedc7e5af78fb479 but this has
the advantage of being spectacularly ugly and slow as well.

Just converting it into a pipeline with

$robots_string
|> fn ($x) => explode(', ', $x)
|> fn ($x) => array_diff($x, $remove)
|> fn ($x) => implode(', ', $x)

has the same characteristics. What I would love to see:

$robots_string
|> explode(', ', $)
|> array_diff($, $remove)
|> implode(', ', $)

While that does look like partial function application, it does not need to
be. It could be just syntactic sugar. Namely, in the expression following
|> a $ is replaced by the entire expression before the |>. Step by step:

explode(', ', $robots_string)
|> array_diff($, $remove)
|> implode(', ', $)

array_diff(explode(', ', $robots_string), $remove)
|> implode(', ', $)

implode(', ', array_diff(explode(', ', $robots_string), $remove))

We could use any other symbol but I liked the $ sign here because the
entire point is not needing a temporary variable between steps so the $
sign stands for "unnamed temporary variable". I also believe it can't lead
to any ambiguous situation (famous last words).

What do you think of this simple version?

On Tue, Jul 18, 2023 at 2:57 PM Olle Härstedt olleharstedt@gmail.com
wrote:

2023-07-17 21:57 GMT+02:00, Larry Garfield larry@garfieldtech.com:

2023-07-17 18:58 GMT+02:00, Larry Garfield larry@garfieldtech.com:

2023-07-17 14:25 GMT+02:00, Karoly Negyesi karoly@negyesi.net:

Hi,

I tried to read on why the pipe RFC failed but by and large I also
failed.

The discussion on https://github.com/php/php-src/pull/7214 is very
short.

https://externals.io/message/114770 is not so short but it seems not
to
cover the latest version which uses first class functions?

Could someone please give me a summary why it failed? I really would
like
to see it succeed :) I am writing code if not daily but certainly
weekly
that certainly looks like a pipeline.

The pipe RFC was kinda forced in before a deadline, no?

My own two cents:

• It's trivial to implement a pipe() function or a Pipe class
• A Pipe class is better than both a function and built-in operator,
  since it can be configured with custom behaviour, e.g. stop or throw
  on empty payload, or repeat on a collection, or even with parallelism
  or concurrency
• If I had voting rights, I'd vote in favor in a pipe operator :)

From my recollection, there were a couple of things involved.

1. It was intended to pair with the PFA RFC, which didn't pass, which
   made
   it a bit less compelling.
2. It was close to the RFC deadline, and it seems people get squeamish
   around that.
3. Some folks wanted Hack-style pipes instead of the pipes used by
   every
   other language with pipes. I've written before on why that's a worse
   design.
4. Arguments that it can be done in user space, which is not true, as I
   have
   a user-space implementation and it's comparatively cumbersome and
   definitely
   slower than a native operator would be.
5. General "meh" attitude on FP features in general from some people.

Side note to Olle: If you want a customizable pipe, you've just
described
a
Monad. :-) It's literally "contextually-sensitive func concatenation."
A
monadic bind operator would be harder to do with PHP's weaker type
system,
but there are ways it could be done.

Mm I don't really agree with that, I think monads make sense only in
languages which support them syntactically. A Pipe class is a very
straight-forward construction, and the blog posts I've read about
monads in PHP don't look pretty at all; lots of syntactic noise going
on. But that's another discussion... :)

At its most basic:

class Foo {
public function __construct(public readonly mixed $val) {}

public __bind(callable $c) {
return $c($this->val);
}
}

new Foo('beep') >>= func(...);

Where >>= is the operator that translates to "Call __bind() on the LHS
object with the callable on the RHS." Poof, we now have a monad
operator.
This one is effectively the same as |> as it doesn't do anything, but you
can do whatever you want in the __bind() method.

1. You also want syntactic sugar around this to "flatten" monadic
   usage; in OCaml it's let*.

2. This way you won't get read-process-write pipelines as first-class
   values, which you can do if you just make a Pipe class instead. I
   think. Correct me if I'm wrong. :)

Olle

PHP at the moment leans heavily on the "null is error and build tooling around that" approach

Yep, you should never use NULL in your code, the following is catastrophically bad...

$search = ($_GET['q'] ?? NULL);

$search = (isset($_GET['q']) ? $_GET['q'] : NULL); // Pre PHP 7

$search = filter_input(INPUT_GET, 'q');

$search = $request->input('q'); // Laravel
$search = $request->get('q'); // Symfony
$search = $this->request->getQuery('q'); // CakePHP
$search = $request->getGet('q'); // CodeIgniter

$search = json_decode('{"q":null}');

And all fields in the database must be set to NOT NULL, never use things like LEFT JOIN, etc... :-(

Craig

2023-07-18 17:13 GMT+02:00, Larry Garfield larry@garfieldtech.com:

2023-07-18 14:48 GMT+02:00, someniatko someniatko@gmail.com:

I am glad this topic arose! I was also planning to write on this topic
to
the internals mailing list, but have abandoned this idea, because I feel
it
might be inconvenient for the real active PHP developers on the list to
receive too many emails from the people which don't actively participate
in
the development itself.

My interest in the pipe operator might seem a little non-standard -
basically what I'd really want to see is a nullable pipe operator!

There is a popular library github.com/schmittjoh/php-option, which has
250
MILLION installations. Basically what it provides is a class-wrapper of
a
value of lack thereof: it's either Some<Type> or None.

I'd just like to mention that the Option type comes from FP and it's
not necessarily needed in PHP-land where we have flow-sensitive type
checkers like Psalm (a nullable type ?int or such is refined to just
int after a null check). Flow-sensitive type-checking was not
invented when the Option type was first created, so adding it to PHP
is basically stepping back in time, from my point of view.

As I've written before[1], there's a lot of overlap in different
error-flow-control options. PHP at the moment leans heavily on the "null is
error and build tooling around that" approach, which has its pros (mainly
simplicity) and cons (lack of information). That mostly obviates the need
for a Maybe type, but not entirely. Right now, there is no "null pipeline"
option in the language like someniako is describing.

In some sense, that's also trivial to do in user-space[2], which leads
easily to

$foo
|> maybe(bar(...))
|> maybe(baz(...))
|> maybe(beep(...));

Which isn't terrible, but also isn't ideal. I don't think I'd oppose a
nullsafe pipe if there's interest (though again, we need interest in pipes
in general first).

However, that runs into the related problem that Maybe is... the weaker way
of handling error context. In most cases I prefer a Result/Either type,
which doesn't map cleanly to null handling. That could be done as a
user-space monad (as above, with just a class and method or a magic method
and dedicated operator). Doing it more natively would require deeper
language hooks. For instance, Rust has the ? suffix on any expression,
which means "if this evaluates to an Error case Result, just return that
Result." That wouldn't fit well in PHP, though.

As I noted in [1], one option would be to allow an object to flag itself as
an error object, and then null-check operators would treat that as null. So
given $result = foo($a)->bar(), if foo() returns an error object then
$result is assigned to that error object and bar() is never called. I'm
still not sure if I like that approach myself, but am open to hear what
others think.

To get back on topic, I do think a pipe operator and concat operator are
valuable in their own right, and have ample use cases even without mixing in
monads or nullables or things like that. We should add them. We can
consider adding more robust branching options as well, (be that >>=, ?|>, or
something else), but be aware that beyond the very trivial case that will
necessarily involve user-space code for many use cases and we'll need to
support that. (Which basically comes down to >>= and making monadic classes
easier to work with, but also runs into the generics problem, and that's its
own mess.)

[1] https://peakd.com/hive-168588/@crell/much-ado-about-null
[2] https://github.com/Crell/fp/blob/master/src/composition.php#L39

--Larry Garfield

Any comment on a pipe (or piped process) as a first-class value? When
you use |> the functions are immediately applied, which might not be
what you want. You can lazify it by wrapping it in a lambda, but I
think that decreases the value of the pipe concept in itself. One
strength is the ability to split the decision about what to glue
together from the decision on how to execute it. You kinda get some
light-weight metaprogramming ability that way.

Well i guess such a pipe-concept is pretty far removed from the simple
pipe operator. :) And also already possible with existing OOP
concepts, callable classes, and now the (...) syntax.

Olle

On Tue, Jul 18, 2023 at 8:05 AM Robert Landers landers.robert@gmail.com
wrote:

On Tue, Jul 18, 2023 at 3:18 PM Olle Härstedt olleharstedt@gmail.com
wrote:

2023-07-18 14:48 GMT+02:00, someniatko someniatko@gmail.com:

I am glad this topic arose! I was also planning to write on this topic
to
the internals mailing list, but have abandoned this idea, because I
feel it
might be inconvenient for the real active PHP developers on the list to
receive too many emails from the people which don't actively
participate in
the development itself.

My interest in the pipe operator might seem a little non-standard -
basically what I'd really want to see is a nullable pipe operator!

There is a popular library github.com/schmittjoh/php-option, which
has 250
MILLION installations. Basically what it provides is a class-wrapper
of a
value of lack thereof: it's either Some<Type> or None. I also
maintain
a similar library
https://packagist.org/packages/someniatko/result-type
which fixes some shortcomings of the original one related to the static
analysis, but this is another story. Basically what the stats tell us
is
that such stuff is popular among the PHP community.

In my eyes, it is actually semantically equivalent to the nullable PHP
types: ?Type. And some operations provided by the lib, are actually
covered by PHP itself, which has multiple null-friendly operators:
$option->getOrElse($defaultVal) --> $nullable ?? $defaultVal
$option->isEmpty() --> $nullable === null
$option->getOrThrow(new \Exception('blah')) --> $nullable ?? throw new \Exception('blah')

I'd like to use the arguably "more idiomatic" native PHP nullables,
rather
than a foreign-feeling userspace construct, if they were more
convenient.

But there is a very important operation, map(), which is
unfortunately
not covered by the native PHP, which is Option::map(), and here is a
real-world example:

return $repository->getById($idFromHttpRequest)
    ->map($serializer->serializeToJson(...)) // only executes when the
Option is Some, not None
    ->map(fn (string $json) => new Response(status: 200, content:

$json))

->getOrElse(new Response(status: 404));

Ehm, wouldn't that be the same as a Pipe class that's configured to
stop on null?

public function getThing($id) {
return new Pipe(
$this->getData(...),
$this->serializeData(...),
$this->mapToResponse(...)
)
->stopOnEmpty()
->from($id)
->run();
}

Wait, are you using map() for arrays or not? Looks like not.

Olle

--

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

I might be venting, but, I wish the operators RFC had passed...

I don't think I will re-propose it with the current set of voters tbh. The
main people who contribute to the Zend folder (the core engine/compiler
parts) were highly skeptical of it, with at least two telling me flat out
that they would vote no even on a hypothetical perfect feature design. Very
few contributors actually touch large parts of that area of the engine, so
most voters tend to take the opinions of those 5-6 voters very seriously on
such proposals. As I don't think it's possible for me to convince those 5-6
people, I don't think it would be a good idea to re-propose, because even
if I did get a 2/3 vote on it, I feel like the people most responsible for
helping me maintain the feature would not be very happy/willing to do so,
and that would probably harm the PHP project in other ways.

Jordan