Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <B6.60.46740.3CD70F65@pb1.pair.com>
To: internals@lists.php.net
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
Date: Mon, 21 Mar 2016 18:03:27 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: RFC Proposal: Maybe monad and execution time polymorphic methods
From: me@stephencoakley.com (Stephen Coakley)

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 everything,
> 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 Maybe
> 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. But
> 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 check
> for null ever again in my life. So my code can be free of nulls. So I can
> 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ínez

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 easy 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 
object, and so I tend to look for a more type-safe solution in PHP. 
There is already 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 PHP 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?

-- 
Stephen