Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.173 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <B6.60.46740.3CD70F65@pb1.pair.com>
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
	<B6.60.46740.3CD70F65@pb1.pair.com>
Date: Mon, 21 Mar 2016 22:09:38 -0600
Message-ID: <CAFMT4NqxhGGo-supviHg20PtS0YM3Kyeife8UB0Jv-mY_gr0vw@mail.gmail.com>
To: Stephen Coakley <me@stephencoakley.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution time
 polymorphic methods
From: levim@php.net (Levi Morrison)

On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley <me@stephencoakley.com> wr=
ote:
> On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote:
>>
>> So I want to "return a NULL". I want to express uncertainty, a
>> nonexistence. But I want to express that I will return something. And I
>> want to have this NULL checking at interpretation time. I want everythin=
g,
>> and none of the drawbacks. As we say here in Argentina, I want the bread
>> and the cake. What can we do to have it? After a bit of thought the Mayb=
e
>> monad came to me.
>>
>> My experience in Haskell reminded me of this. To have a structure than
>> represents uncertainty, is the best way to take away the responsibility
>> from NULL. To express it in no other way. But my experience in Java has
>> taught me that Optional of something is not a good way to tackle the
>> problem. I still have to check if my Optional isEmpty. I still have to
>> check for null. That is because Java has that type erasure after
>> compilation time that doesn't allow me to play nice with polymorphism. B=
ut
>> maybe PHP can. Maybe PHP will give me the polymorphism at execution time
>> to
>> discern an empty Maybe from the one that is not. So I don't have to chec=
k
>> for null ever again in my life. So my code can be free of nulls. So I ca=
n
>> express uncertainty and nonexistance, while I return a User from my
>> repository.
>>
>> I hope someone would like this idea. I'm also open to suggestions.
>> Kind regards
>> Facundo Mart=C3=ADnez
>
>
> First of all, let me confess that I absolutely love monad (or composite)
> types, and I greatly prefer a Maybe over something that may or may not be
> null. There's a slight problem however, and something that will not be ea=
sy
> to get around: a lack of generics.
>
> This is an issue with wrapper types in general in PHP, where you want to
> wrap an object in some other type. You lose type safety on the inner obje=
ct,
> and so I tend to look for a more type-safe solution in PHP. There is alre=
ady
> a generics RFC out there (https://wiki.php.net/rfc/generics) but
> implementing it won't be trivial.
>
> Implementing (or defining) a good Maybe type also depends on better
> composite/enum types (https://wiki.php.net/rfc/enum is drafted, but doesn=
't
> support what we need). The classical definition would be (hypothetical PH=
P
> syntax):
>
> enum Maybe<T>
> {
>     Some {
>         public function __construct(T $value);
>         public function isSome(): bool {
>             return true;
>         }
>         public function into(): T {
>             return $this->value;
>         }
>     },
>     None {
>         public function isSome(): bool {
>             return false;
>         }
>         public function into(): T {
>             throw new Error();
>         }
>     }
> }
>
> Such a definition depends on two different things we don't have right now=
 in
> PHP. Maybe there's a simpler way, but hopefully you have a better
> alternative?

This requires you to query state with `isSome()`. This is hardly any
different from a null case, just more code. We can already accurately
distinguish between `null` and another value.

If we want an option for safer PHP code I think we need a safer
construct that requires exhaustive matching (such as Rust's `match`).
I'm not sure how to pull that off.