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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
