Front page | perl.perl5.porters |
Postings from August 2021
Re: Pre-RFC: Real "boolean" SV type
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
August 6, 2021 08:08
Subject:
Re: Pre-RFC: Real "boolean" SV type
Message ID:
f3a80680-3a7d-4ac3-cceb-263c25115372@darrenduncan.net
On 2021-08-05 11:04 p.m., Yuki Kimoto wrote:
> 2021-8-6 9:25 Darren Duncan wrote:
> What's needed is a boolean type whose values are disjoint from all numbers and
> all strings, the latter 2 also being disjoint from each other.
>
> One needs to be able to round-trip losslessly, which would only happen if these
> were disjoint.
>
> JSON has the types of string, number, and boolean.
>
> Perl don't has types of string, number, and boolean at least from the user world.
> .
> These are all scalar type.
>
> Perl, on the other hand, has types internally represented by flags.
>
> Is this topic talking about the types of the user world, or about the internal
> types?
Anything that can be discovered from the user world, eg by writing Perl code, is
part of the user world.
Given X and Y, if there exists any operation that one can write in pure Perl,
optionally using any core/bundled modules, that would behave differently in any
way when X is used as an input versus when Y is used as an input, for example if
there exists any function F such that F(X) and F(Y) have different results, then
X and Y are logically NOT the same value, though X and Y may have a lot of
similarities and for many use cases are effectively the same, but they are not
actually the same value.
As far as I know, it is possible and common to read the flags for Perl scalars,
and some serialization or other modules do so in order to drive their behavior.
Whether you call them internal distinctions or not, to a large extent Perl does
distinguish integers and floats and strings etc.
It seems to me that this "real boolean" proposal and some other mentioned things
are seeking for Perl to be updated to fix the edge cases so it is possible to be
completely unambiguous about whether a scalar is a boolean vs integer vs float
vs string etc (also octet strings and character strings should be clearly
distinguishable from each other as well somehow).
Whatever terminology you use or how its implemented, the proof of the pudding is
in the eating.
I mentioned solid criteria for knowing whether Perl has been sufficiently
improved to satisfy what it seems this proposal wants and what I want, which is
that Perl has a clear way of distinctly representing what are common disjoint
types in other data formats or languages, so we can round-trip values between
them without loss.
So JSON string/number/boolean can pass JSON->Perl->JSON and the second JSON is
identical to the first.
If you can't tell from the Perl value whether something started as a boolean or
number or string, then Perl has lost important information, and not losing it
demonstrates a fix for that.
-- Darren Duncan
Thread Previous
|
Thread Next