develooper Front page | perl.perl5.porters | Postings from August 2021

Re: Pre-RFC: Real "boolean" SV type

Thread Previous | Thread Next
Darren Duncan
August 6, 2021 08:08
Re: Pre-RFC: Real "boolean" SV type
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About