Mailing List Archive

On Thu, Aug 05, 2021 at 01:35:19PM +0200, Salvador Fandi?o wrote:
> On 5/8/21 12:58, Paul "LeoNerd" Evans wrote:
>
> > I don't yet have a good thought about "no", but since PL_sv_yes carries
> > its own stringification PV, it's possible that sv_setsv could notice
> > it's that special value and store it as-is, with SvLEN == 0, into the
> > target. So it's now possible to distinguish any true bool value, by
> >
> > SvIV(sv) == 1 && SvPVX(sv) == SvPVX(&PL_sv_yes)
>
> That would impede one for having boolean dualvars.
>
> Programmers may want to have booleans that stringify as True/False, T/F,
> Yes/No, 1/0, or the current 1/"".
>
> Actually, I would say the current PL_sv_no stringification ("") is not the
> one the programmer needs in most cases.

I think that this is relevant discussion for an RFC proper, not this Pre-RFC
thread. Thanks for raising this potential problem early.

Consensus seems to be that having boolean values that know that they are
boolean values is worth an RFC. How we best implement it isn't obvious
without experimenting, and discovering the drawbacks of any approach.

Nicholas Clark

On Wed, Aug 04, 2021 at 03:30:35PM -0700, Aaron Priven wrote:

> I don???t have a problem with the proposal per se, but it???s hard for
> me to believe that inferring what type a value should be from its
> initial assignment is going to be reliable.
>
> Surely there???s a lot of extant code like
>
> if ($condition) {
> $flag = $x eq $y;
> } else {
> do_something();
> $flag = 1;
> }
> $count+= $flag;
>
> Is $flag a boolean or an integer?

I'd expect that It Depends.

But I'd expect $count to be an integer, because + always returns a
number, just like it would be if you say this:

$car_contents = '11 clowns';
$count += $car_contents;

--
David Cantrell | Pope | First Church of the Symmetrical Internet

Deck of Cards: $1.29.
"101 Solitaire Variations" book: $6.59.
Cheap replacement for the one thing Windows is good at: priceless
-- Shane Lazarus

2021-8-5 19:58 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

>
> But now we're getting into the weeds of implementation. I think my
> original discussion has demonstrated that people do feel a need for
> this ability - so I'll write the RFC and we can worry about the "how"
> later
>
>
I think what people really want is a Boolean standardization of JSON.

Perl has no type in the language specification, however it is useful to
have a flag that it is currently a Boolean value.

true and false are functions to create bool value, not bool type.

I think weird edge cases will appear, however I think it's possible to
reduce them.

On 2021-08-05 5:10 p.m., Yuki Kimoto wrote:
> 2021-8-5 19:58 Paul "LeoNerd" Evans wrote:
>
> But now we're getting into the weeds of implementation. I think my
> original discussion has demonstrated that people do feel a need for
> this ability - so I'll write the RFC and we can worry about the "how"
> later
>
>  I think what people really want is a Boolean standardization of JSON.
>
> Perl has no type in the language specification, however it is useful to have a
> flag that it is currently a Boolean value.
>
> true and false are functions to create bool value, not bool type.
>
> I think weird edge cases will appear, however I think it's possible to reduce them.

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.

A JSON false or true converted to Perl and back to JSON needs to still be JSON
false or true respectively.

A JSON number 0 or 1 converted to Perl and back to JSON needs to be a JSON
number 0 and 1.

A JSON empty string '' or strings '0' or '1' need to convert to Perl and back to
JSON as those same strings.

And so on.

If there wasn't a disjoint boolean type and Perl functions false/true just
generated numbers or strings, then we wouldn't have round-tripping, which means
we LOSE INFORMATION.

So not losing information is what is desired.

-- Darren Duncan

2021-8-6 9:25 Darren Duncan <darren@darrenduncan.net> 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.
>
> A JSON false or true converted to Perl and back to JSON needs to still be
> JSON
> false or true respectively.
>
> A JSON number 0 or 1 converted to Perl and back to JSON needs to be a JSON
> number 0 and 1.
>
> A JSON empty string '' or strings '0' or '1' need to convert to Perl and
> back to
> JSON as those same strings.
>
> And so on.
>
> If there wasn't a disjoint boolean type and Perl functions false/true just
> generated numbers or strings, then we wouldn't have round-tripping, which
> means
> we LOSE INFORMATION.
>
> So not losing information is what is desired.
>
> -- Darren Duncan
>

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?

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

On Wed, 4 Aug 2021 15:58:19 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> I propose the addition of a new SV type, of SVt_BOOL. Should I write
> an RFC?

The overwhelming response to this thread was "yes" (a boolean answer, I
notice ;) ) so I have now written a first draft:

https://github.com/Perl/RFCs/pull/3

> *: Where "postcard" means: **PLEASE KEEP REPLIES SHORT**. This is a
> pre-RFC question. Replies should be limited to the question of whether
> I should write the RFC - not about the feature itself.

And *now* you may comment on the actual detail of the proposal - as
comments on the github PR please (not as replies here).

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 4 Aug 2021 15:58:19 +0100, "Paul \"LeoNerd\" Evans"
<leonerd@leonerd.org.uk> wrote:

> I propose the addition of a new SV type, of SVt_BOOL. Should I write
> an RFC?

Better late than never (and maybe you already started the RFC), but I
am catching up on mail and want to express my support

+1 ????

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org