Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112714
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <6f51556b-a566-45d2-939e-3d6c3441eb00@www.fastmail.com>
In-Reply-To: <a67b43e8-1940-686b-445a-1586d718fc8c@gmail.com>
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
 <C9E7D7C8-2EB8-479A-B0BF-E992172765EE@newclarity.net>
 <30906866-1971-8395-05a0-fd78d054bb89@gmail.com>
 <CAJpLVh3c2o+RDjEg+GenLJa9rh5iLXMu8VZnbkdM0_n0FmfM=A@mail.gmail.com>
 <c9949f2e-79a7-4a35-9d0e-c8a8ba861fb0@www.fastmail.com>
 <0C621FEF-B76F-41F5-A5A8-E6F24D69DD3D@pmjones.io>
 <a67b43e8-1940-686b-445a-1586d718fc8c@gmail.com>
Date: Sat, 02 Jan 2021 15:25:08 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Analysis_of_property_visibility,_immutability,_a?=
 =?UTF-8?Q?nd_cloning_proposals?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jan 2, 2021, at 12:56 PM, Rowan Tommins wrote:
> On 01/01/2021 20:31, Paul M. Jones wrote:
> > The complaints against the incomplete and inconsistent immutability of PSR-7 have merit.
> 
> 
> The big mistake of PSR-7, in my view, is mixing immutable objects with 
> streams, which are inherently mutable/stateful. I wonder if there are 
> any lessons to be learned there in terms of what kinds of immutability 
> the language should encourage / make easy.
> 
> For instance, is it better to constrain entire objects to be immutable 
> rather than individual properties? And should there be restrictions on 
> what you can declare as immutable, since "immutable resource" is largely 
> nonsensical?
> 
> Or is it rather a reflection that building purely immutable 
> implementations is hard, and the language needs other facilities 
> (monads? ownership?) to mix in those parts that don't fit?
> 
> Regards,

I rarely hear that called out as a PSR-7 complaint specifically, in practice, but moving on...

IMO, it's better to put the focus on immutable properties.  There are use cases where you want only some properties to be immutable, but not the whole class.  If you do want the whole class, then marking all the properties immutable is effectively the same thing.

Though, again, in practice, at least in PHP, I don't think immutable properties should be the goal.  Asymmetric visibility lets us built safely immutable-from-the-outside objects that are "up to you" on the inside.  I think that gives us a better end result given the nature of PHP.  In other languages that wouldn't make as much sense, but PHP is what it is.

Copy on write makes "immutable data structures" not something we need to build explicitly; we get "close enough" for free.  If you really wanted to micro-optimize the memory and CPU usage further than that... go build it in Rust instead.

Wrapping immutable behavior around IO is... ugly, gross, and disgusting. :-)  Even supposedly Twue Pure languages like Haskell don't actually do that; it just hides the IO mutability in the engine and whistles innocently while muttering "monad" under its breath. :-)

At least in the abstract, immutability and IO would require IO primitives that returned both a read value and a new stream pointer, possibly consuming and destroying the old one.  If a stream is seekable, you could conceptually do something like:

$fp = file_open('foo.txt');
[$line, $fp2] = read_line($fp);

In which $fp2 and $fp refer to the same file stream on disk, but their stream pointers are different.  In practice you'd likely use $fp as the second parameter and lose the old reference, which is good enough.  That's a bit clumsy, though, and where one might use something monad-based to make the code a bit simpler.  I don't know off hand what that would look like, though.

[$line1, $fp2] = read_line($fp);
[$line2, $fp2] = read_line($fp);
[$line3, $fp2] = read_line($fp);
[$line4, $fp2] = read_line($fp);

In the above example, since $fp is never overwritten, all 4 $line variables are the same thing.

If a stream is not seekable, then it would have to consume and destroy $fp in the process (unset it).  So:

[$line1, $fp2] = read_line($fp);
[$line2, $fp2] = read_line($fp);

The second line would throw an error that $fp "has been consumed" or something like that.  But even that still creates potential for spooky-action-at-a-distance if $fp was passed into a function, gets read in that function, and then the parent call scope has a broken $fp lying around.

IO is inherently impure and mutable, and always will be.  I don't think it's realistic for us to fix that, certainly not in PHP.  Instead we should be making it easy to encapsulate the IO into safe corners where you can guard it carefully and keep everything else as pure as reasonable.

All of which is why the scope I'm looking at is not how to make PHP Haskell-esque pure.  It's how do we make it more ergonomic for developers to build stateless code in those places where it's reasonable to do so.  It's a much less ambitious, but therefore more achievable, scope.

--Larry Garfield