On 07/04/2024 23:50, Jordan LeDoux wrote:
By a "scalar" value I mean a value that has the same semantics for reading, writing, copying, passing-by-value, passing-by-reference, and passing-by-pointer (how objects behave) as the integer, float, or boolean types.
Right, in that case, it might be more accurate to talk about "value types", since arrays are not generally considered "scalar", but have those same behaviours. And Ilija recently posted a draft proposal for "data classes", which would be object, but also value types: [RFC][Concept] Data classes (a.k.a. structs) - Externals
As I mentioned in the discussion about a "scalar arbitrary precision type", the idea of a scalar in this meaning is a non-trivial challenge, as the zval can only store a value that is treated in this way of 64 bits or smaller.
Fortunately, that's not true. If you think about it, that would rule out not only arrays, but any string longer than 8 bytes long!
The way PHP handles this is called "copy-on-write" (COW), where multiple variables can point to the same zval until one of them needs to write to it, at which point a copy is transparently created.
The pointer for this value would fit in the 64 bits, which is how objects work, but that's also why objects have different semantics for scope than integers. Objects are potentially very large in memory, so we refcount them and pass the pointer into child scopes, instead of copying the value like is done with integers.
Objects are not the only thing that is refcounted. In fact, in PHP 4.x and 5.x, *every* zval used a refcount and COW approach; changing some types to be eagerly copied instead was one of the major performance improvements in the "PHP NG" project which formed the basis of PHP 7.0. You can actually see this in action here: Online PHP editor | output for oPgr4
This is all completely transparent to the user, as are a bunch of other memory/speed optimisations, like interned string literals, packed arrays, etc.
So, there may be performance gains if we can squeeze values into the zval memory, but it doesn't need to affect the semantics of the new type.
In general I would say that libbcmath is different enough from other backends that we should not expect any work on a BCMath implementation to be utilized in other implementations. It *could* be that we are able to do that, but it should not be something people *expect* to happen because of the technical differences.
Some of the broader language design choices would be transferable though. For instance, the standard names of various calculation functions/methods are something that would remain independent, even with the differences in the implementation.
Yes, that makes sense. Even if we don't have an interface, it would be annoying if one class provided $foo->div($bar), and another provided $foo->dividedBy($bar)
For money calculations, scale is always likely to be a more useful configuration. For mathematical calculations (such as machine learning applications, which I would say is the other very large use case for this kind of capability), precision is likely to be the more useful configuration. Other applications that I have personally encountered include: simulation and modeling, statistical distributions, and data analysis. Most of these can be done with fair accuracy without arbitrary precision, but there are certainly types of applications that would benefit from or even require arbitrary precision in these spaces.
This probably relates quite closely to Arvid's point that for a lot of uses, we don't actually need arbitrary precision, just something that can represent small-to-medium decimal numbers without the inaccuracies of binary floating point. That some libraries can be used for both purposes is not necessarily evidence that we could ever "bless" one for both use cases and make it a single native type.
My intuition at the moment is that a single number-handling API would be challenging to do without an actual proposed implementation on the table for MPDec/MPFR.
I think it would certainly be wise to experiment with how each library can interface to the language as an extension, before spending the extra time needed to integrate it as a new zval type.
But even with these extensions available in PHP, they are barely used by developers at all because (at least in part) of the enormous difference between PECL and PIP. For PHP, I do not think that extensions are an adequate substitute like PIP modules are for Python.
Yes, this is something of a problem. On the plus side, a library doesn't need to be incorporated into the language to be widely installed, because we have the concept of "bundled" extensions; and in practice, Linux distributions add a few "popular" PECL extensions to their list of installable binary packages. On the minus side, even making it into the "bundled" list doesn't mean it's installed by default everywhere, and userland libraries spend a lot of effort polyfilling things which would ideally be available by default.
This is, essentially, the thesis of the research and work that I have done in the space since joining the internals mailing list.
Thanks, there's some really useful perspective there.
Regards,
--
Rowan Tommins
[IMSoP]
