Mailing List Archive

On Wed, Aug 4, 2021 at 10:58 AM 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?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.
>

I think this would be an excellent idea, as it would assist with both the
serialization problem and newcomer's expectations.

-Dan

On 8/4/21 7:58 AM, Paul "LeoNerd" Evans wrote:
> I propose the addition of a new SV type, of SVt_BOOL. Should I write an
> RFC?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.
>
I would *LOVE* this in Perl. I thought about requesting it myself but
every other post online asking about boolean in Perl is "you don't need
it in Perl" so I assumed the community was against it.

I support this 1000%. I even support this more than putting *trim()* in
core, but only by a little bit.

- Scott

Yes please.

It would make YAML library authors also happy =)

On Wed, 4 Aug 2021, Paul "LeoNerd" Evans wrote:

> I propose the addition of a new SV type, of SVt_BOOL. Should I write an
> RFC?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>

Hi Paul LeoNerd,

Yes, please write the RFC. Thank you,

Carl Friedberg
President, Comet &Company
165 William St New York NY
Office (212) 233-5470
Cell (917) 861-7819

-----Original Message-----
From: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
Sent: Wednesday, August 4, 2021 10:58 AM
To: Perl5 Porters <perl5-porters@perl.org>
Subject: Pre-RFC: Real "boolean" SV type

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

This type will act much like the existing "booleans" of PL_sv_no and PL_sv_yes, except its type will remain distinct, so it will be possible to distinguish "that SV is a boolean". This is a requirement for certain kinds of data serialisation - such as JSON or MsgPack - and may be useful for many other purposes too.

Still to be determined: a pureperl interface on it. E.g. would this be
possible:

use feature 'bool';

my $yes = true; # new literal value keywords
my $no = false; #

use Scalar::Util 'svtype';

is( svtype($yes), "BOOL", 'true is SVt_BOOL');

Thoughts on a postcard*.


*: 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.

--
Paul "LeoNerd" Evans

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

"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:

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

Yes please!

> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');

Should these also pass?

is( svtype(!0) ,"BOOL", 'PL_sv_yes is SVt_BOOL' );
is( svtype(!1) ,"BOOL", 'PL_sv_no is SVt_BOOL' );

And if so, only in the scope of `use feature 'bool';`, or everywhere?

- ilmari

Yes, write RFC please.

This is a great idea, and something Perl is lacking in.

Thank you.


On Wed, Aug 4, 2021 at 6:58 PM 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?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.
>
> --
> 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, 04 Aug 2021 16:24:45 +0100
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:

> Should these also pass?
>
> is( svtype(!0) ,"BOOL", 'PL_sv_yes is SVt_BOOL' );
> is( svtype(!1) ,"BOOL", 'PL_sv_no is SVt_BOOL' );

Indeed - I forgot to mention but I'd also propose making PL_sv_yes/no
themselves be SVt_BOOL, rather than their current form of SVt_PVIV.

> And if so, only in the scope of `use feature 'bool';`, or everywhere?

I don't see why it can't be everywhere. A perl new enough to have
svtype() would be new enough in which no/yes are true booleans and not
PVIVs-in-disguise. The feature guard is really just to guard the `true`
and `false` keyword syntax, rather than the underlying semantics of the
boolean type.

--
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?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.

What are 'true' and 'false' exactly? Are they synonyms for !!1 and !!0
or are they brand new values that stringify to "true" and "false"?

On Wed, 04 Aug 2021 17:44:39 +0200
Tomasz Konojacki <me@xenu.pl> wrote:

> What are 'true' and 'false' exactly? Are they synonyms for !!1 and !!0
> or are they brand new values that stringify to "true" and "false"?

Same thing. I'd suggest having the existing PL_sv_no and PL_sv_yes
constants be SVt_BOOL, and then any existing expression already yields
those. `true` and `false` become new keywords that are just synonyms
for !!1 and !!0 respectively.

As to stringification, while it would be lovely to have them stringify
to "true" and "false", that won't be possible without breaking basically
eeeeeeverything. Which is a bit annoying. :/

--
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, Aug 4, 2021 at 5:45 PM Tomasz Konojacki <me@xenu.pl> wrote:

> What are 'true' and 'false' exactly? Are they synonyms for !!1 and !!0
> or are they brand new values that stringify to "true" and "false"?
>

It's not really about their values, but about identity (that sounded like
it could be about something very different)

Ultimately they're nothing more than special values of 0 and 1, that just
happen to know they're identical (as opposed to equivalent) to false and
true. Most code that isn't a serializer wouldn't care about this, but
there's a lot of code out there that uses serializers.

Leon

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 can appreciate the desire to have serializers work on data without having to pass type information separately, but it seems really unlikely to me that it’s possible to be consistent without being explicit.

-----Original Message-----
From: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
Sent: Wednesday, August 4, 2021 10:58 AM
To: Perl5 Porters <perl5-porters@perl.org>
Subject: Pre-RFC: Real "boolean" SV type

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

--
Aaron Priven, aaron@priven.com, www.priven.com/aaron

On Wed, 4 Aug 2021 15:30:35 -0700
Aaron Priven <aaron@priven.com> 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 can appreciate the desire to have serializers work on data without having to pass type information separately, but it seems really unlikely to me that it?s possible to be consistent without being explicit.

if ($condition) {
$flag = $x eq $y; # boolean
} else {
do_something();
$flag = 1; # not a boolean, replace it with !!1 or true
}
$count+= $flag; # not a boolean

Anyway, yes, it won't magically fix all existing code. But it will give
the users *a way* to create variables that will reliably serialize as
booleans. Of course, often you will have to normalize your values just
before passing them to a serializer, but it's still a huge improvement.

On Wed, Aug 04, 2021 at 03:58:19PM +0100, Paul "LeoNerd" Evans wrote:
> I propose the addition of a new SV type, of SVt_BOOL. Should I write an
> RFC?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.

I think having some sort of boolean type will be useful for
serialization, I'm not sure svtype is the right place to distinguish
them.

Like PV, PVNV etc (and unlike PVAV, PVIO etc) an SV will tend to get
upgraded as more capabilities are needed from it.

If SVt_BOOL is a small SV type like SVt_IV, can such an SV have magic,
or be blessed?

If SVt_BOOL is a large type like SVt_PVMG, simple booleans will be
paying an extra cost they don't need.

It may need a flag instead.

Tony

2021-8-4 23:58 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?
>
>
Because JSON has become the de facto standard for web data, it is good to
manipulate boolean in Perl.

One issue is compatibility with past expressions.

Is there any change of the boolean expression of JSON::PP?

And JSON and YAML modules on CPAN?

There is a little big cost to switch to boolean type, however I think the
benefits are much more.

Thank you!

I fully agree Perl would benefit greatly from having a dedicated boolean type.

This type should be disjoint from numbers/strings/references. So a value that
is a boolean is not one of the others and vice-versa.

Besides new false/true literals, this new boolean would be the official result
type of any comparison operator. So (1 == 1) or (0 == 1) etc would return a new
boolean value and not an integer or string.

If you were to ask, what type are you, of a boolean, it would report its a
boolean and not a string or number.

To keep things Perlish, any generic context expecting a boolean such as an
if-conditional or such can still take values of other types and it would cast
them as a boolean such that existing Perl code doing this would behave as it did
before.

Other Perl types can still be coerced to a boolean in a meaningful way as they
did before. While asking is 0 or '' a boolean would be false, asking if either
is false would be true. Likewise asking if 1 or '1' is a boolean would be
false, but asking if either is true would be true.

This is basically how it works in Raku and that seems a good model to follow.

We would also want an explicit operator or otherwise some kind if idiom that
would reliably cast a falsey or truthy value as an actual false or true.

Casting a boolean as an integer say by adding 0 to it would result in 0 or 1
respectively, and casting a boolean as a string say by catenating empty string
to it would result in '' and '1' respectively, which I think is compatible with
how the results of say (0 == 1) etc stringify now.

To make things easiest to adopt, any end to end operations that work in terms of
numbers or strings should behave the same due to how implicit casting happens
between booleans and those types, so the introduction of real booleans doesn't
change existing code's behavior.

The sole exception would be routines that answer the question, what type is this.

(I also believe byte strings and character strings should be fully disjoint too,
but that's an independent decision, more the topic of the UTF-8 discussion.)

-- Darren Duncan

On 2021-08-04 7:58 a.m., Paul "LeoNerd" Evans wrote:
> I propose the addition of a new SV type, of SVt_BOOL. Should I write an
> RFC?
>
> This type will act much like the existing "booleans" of PL_sv_no and
> PL_sv_yes, except its type will remain distinct, so it will be possible
> to distinguish "that SV is a boolean". This is a requirement for
> certain kinds of data serialisation - such as JSON or MsgPack - and may
> be useful for many other purposes too.
>
> Still to be determined: a pureperl interface on it. E.g. would this be
> possible:
>
> use feature 'bool';
>
> my $yes = true; # new literal value keywords
> my $no = false; #
>
> use Scalar::Util 'svtype';
>
> is( svtype($yes), "BOOL", 'true is SVt_BOOL');
>
> Thoughts on a postcard*.
>
>
> *: 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.
>

On Thu, 5 Aug 2021 at 11:37, Darren Duncan <darren@darrenduncan.net> wrote:

> Thank you!
>
> I fully agree Perl would benefit greatly from having a dedicated boolean
> type.
>

Please do keep in mind the original request:

> *: 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.

The rest of your reply might be more appropriate *after* the RFC has been
written?

Very much support this idea.
One question, how would it handle this annoyance?

#!/usr/bin/env perl
use strict;use warnings;
my @list    = map { rand(50) } 1 .. 10;my $matches = 0;for (@list) {  $matches += $_ > 25; # ???}print "Matches = $matches\n";


Yes, that's an abuse, but it's the kind of crud we see in the wild (and it doesn't throw any warnings);
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl

On Thursday, 5 August 2021, 07:34:36 CEST, Tom Molesworth via perl5-porters <perl5-porters@perl.org> wrote:

On Thu, 5 Aug 2021 at 11:37, Darren Duncan <darren@darrenduncan.net> wrote:

Thank you!

I fully agree Perl would benefit greatly from having a dedicated boolean type.


Please do keep in mind the original request:
> *: 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.
The rest of your reply might be more appropriate *after* the RFC has been written?

On 2021-08-04 11:28 p.m., Ovid via perl5-porters wrote:
> Very much support this idea.
>
> One question, how would it handle this annoyance?
>
> #!/usr/bin/env perl
>
> use strict;
> use warnings;
>
> my @list    = map { rand(50) } 1 .. 10;
> my $matches = 0;
> for (@list) {
>   $matches += $_ > 25; # ???
> }
> print "Matches = $matches\n";
>
> Yes, that's an abuse, but it's the kind of crud we see in the wild (and it
> doesn't throw any warnings);

If my previous suggestion is followed, then the numeric operator += would cause
the result of "$_ > 25" to be cast as an integer which for the boolean true
would be 1, and so the behaviour would be the same as in prior Perl versions. --
Darren Duncan

On 2021-08-04 11:28 p.m., Ovid via perl5-porters wrote:
> One question, how would it handle this annoyance?
>
> #!/usr/bin/env perl
>
> use strict;
> use warnings;
>
> my @list    = map { rand(50) } 1 .. 10;
> my $matches = 0;
> for (@list) {
>   $matches += $_ > 25; # ???
> }
> print "Matches = $matches\n";
>
> Yes, that's an abuse, but it's the kind of crud we see in the wild (and it
> doesn't throw any warnings);

As a further response,

Something else we can do, and we can actually do this independently of the
boolean type stuff, is add new warning types that trigger whenever an implicit
type cast happens, such as when using a string as a number or vice versa.

So though such casting behavior is well defined it can still warn if we consider
that a bad coding design.

In that case though we would also need to have canonical explicit conversion
syntax/routines/operators such that one can replace the then-warning code, which
would include idioms like "0+$str", with something that wouldn't warn because
the conversion is explicit.

-- Darren Duncan

On Thu, Aug 05, 2021 at 11:26:07AM +1000, Tony Cook wrote:
> On Wed, Aug 04, 2021 at 03:58:19PM +0100, Paul "LeoNerd" Evans wrote:
> > I propose the addition of a new SV type, of SVt_BOOL. Should I write an
> > RFC?
> >
> > This type will act much like the existing "booleans" of PL_sv_no and
> > PL_sv_yes, except its type will remain distinct, so it will be possible
> > to distinguish "that SV is a boolean". This is a requirement for
> > certain kinds of data serialisation - such as JSON or MsgPack - and may
> > be useful for many other purposes too.
>
> I think having some sort of boolean type will be useful for
> serialization, I'm not sure svtype is the right place to distinguish
> them.
>
> Like PV, PVNV etc (and unlike PVAV, PVIO etc) an SV will tend to get
> upgraded as more capabilities are needed from it.
>
> If SVt_BOOL is a small SV type like SVt_IV, can such an SV have magic,
> or be blessed?
>
> If SVt_BOOL is a large type like SVt_PVMG, simple booleans will be
> paying an extra cost they don't need.
>
> It may need a flag instead.

It can't be implemented as a type.

Much like the "was this originally an integer/was this originally a string"
problem can't also be implemented as a type.

In that, if you need to bless a boolean, then it has to be SVt_PVMG.

And for certain operations, the *value* needs to pass through a PVLV without
loosing it's "I'm a boolean"-ness. I think tied hashes; but certainly this;

#!/usr/bin/perl -w

use strict;
use Devel::Peek;

sub foo {
my $val = 3.14;
print STDERR "Here's it's NV\n\n";
Dump $val;
print STDERR "\n\nWhat comes in is *funky*;\n\n";
Dump($_[0]);
$_[0] = 3.14;
}

my %h;

foo($h{pi});

print STDERR "\n\nWhat you end up with is PVNV:\n\n";

Dump(\%h);

__END__


Here's it's NV

SV = NV(0x11007a8) at 0x11007b0
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 3.14


What comes in is *funky*;

SV = PVLV(0x1113f18) at 0x10dffb0
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x1101f18
MG_VIRTUAL = &PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x10e0190
SV = PV(0x10e09a0) at 0x10e0190
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x11130b8 "pi"\0
CUR = 2
LEN = 10
TYPE = y
TARGOFF = 0
TARGLEN = 1
TARG = 0x11007e0
FLAGS = 0
SV = PVHV(0x10e6420) at 0x11007e0
REFCNT = 2
FLAGS = (SHAREKEYS)
ARRAY = 0x0
KEYS = 0
FILL = 0
MAX = 7


What you end up with is PVNV:

SV = IV(0x10dffb0) at 0x10dffb0
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x11007e0
SV = PVHV(0x10e6420) at 0x11007e0
REFCNT = 2
FLAGS = (SHAREKEYS)
ARRAY = 0x1108d58 (0:7, 1:1)
hash quality = 100.0%
KEYS = 1
FILL = 1
MAX = 7
Elt "pi" HASH = 0x694d4f73
SV = PVNV(0x10deb28) at 0x10fb130
REFCNT = 1
FLAGS = (NOK,pNOK)
IV = 0
NV = 3.14
PV = 0


So PVLVs also have to be able to hold booleans.

Types aren't the way to go. A flag might be, but it might also be possible to
implement it as

true: SvPOK(sv) && SvPVX(sv) == PL_Yes)
false: SvPOK(sv) && SvPVX(sv) == PL_No)

and have Perl_sv_setsv_flags() do SV copies like that for booleans.

(That's the *only* place that copies SVs. So it can be changed.)


Also


We need an API to say "how should I best serialise this SV?"

(This became apparent during the "IVs vs PVs" thread but I hadn't replied to
it there.)

Abstract all the "logic" about what flags might mean what into a clear API,
so that

1) We can change the internals in the future
2) We can add it to ppport.h to express the "best effort' for the past.


Pass a SV, return a value from an enumeration, which I think *starts*

* undef
* boolean
* integer
* float
* string

but needs at least one escape hatch for "clearly this is a dualvar"
and it's also not clear how to handle overloaded references.
Unless the rule is that anything passed in that's SvROK() returns "reference"
and the caller gets to figure it out.


(And before anyone starts to argue that string should be spit into "bytes" and
"text" - you *can't* know that based on just SVf_UTF8. This isn't what we
want, but it *is* the way it is currently.)


So yes, please, an RFC on booleans would be great. But the language level
semantics are what are important first - I don't think that the correct
implementation is obvious yet.

Nicholas Clark

On Thu, 5 Aug 2021 07:29:15 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> On Thu, Aug 05, 2021 at 11:26:07AM +1000, Tony Cook wrote:
> > I think having some sort of boolean type will be useful for
> > serialization, I'm not sure svtype is the right place to distinguish
> > them.
> >
> > Like PV, PVNV etc (and unlike PVAV, PVIO etc) an SV will tend to get
> > upgraded as more capabilities are needed from it.
...
> > It may need a flag instead.
>
> It can't be implemented as a type.
>
> Much like the "was this originally an integer/was this originally a
> string" problem can't also be implemented as a type.
>
> In that, if you need to bless a boolean, then it has to be SVt_PVMG.
>
> And for certain operations, the *value* needs to pass through a PVLV
> without loosing it's "I'm a boolean"-ness. I think tied hashes; but
> certainly this;

Ahyes; you're both right of course, for exactly the same reasons as my
previous suggestion about SVt_PV_was_IV vs SVt_IV_was_PV. You'd think
after that first one I'd learn, but no... ;)

I'll mention that in the RFC and point out it really does need a flag -
SvBOK() or somesuch?

--
Paul "LeoNerd" Evans

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

On Thu, Aug 05, 2021 at 11:42:21AM +0100, Paul "LeoNerd" Evans wrote:
> On Thu, 5 Aug 2021 07:29:15 +0000
> Nicholas Clark <nick@ccl4.org> wrote:

> > And for certain operations, the *value* needs to pass through a PVLV
> > without loosing it's "I'm a boolean"-ness. I think tied hashes; but
> > certainly this;
>
> Ahyes; you're both right of course, for exactly the same reasons as my
> previous suggestion about SVt_PV_was_IV vs SVt_IV_was_PV. You'd think
> after that first one I'd learn, but no... ;)

Third time lucky? :-)

I realised (after I sent the mail) that for scalars it's something like

"SV types are about storage"
"flags are about values"

and hence (for scalars) as values are getting copied, it's the values that
need to hold this (meta)information

Whereas, for aggregates, all the XS tests are for things like

SvTYPE(hv) == SVt_PVHV

meaning that until C(42+5i) adds junctions as a fundamental type, we're
stuck with "hashes and symbol tables have to have a single common type"
(similarly all the things that AVs want to play at)

> I'll mention that in the RFC and point out it really does need a flag -
> SvBOK() or somesuch?

It might be possible to implement *without* a flag, as I postulated,
using PL_Yes and PL_No, and some changes to sv_setsv_flags.

(Which will need to be changed come-what-may to deal with booleans)

So I think it "really does" is not correct - "might" is more accurate.

Nicholas Clark

On Thu, 5 Aug 2021 10:52:51 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> I realised (after I sent the mail) that for scalars it's something
> like
>
> "SV types are about storage"
> "flags are about values"

Yes - how I've usually explained the thing about SVt_NV, SVt_PV and
SVt_PVNV is that the SvTYPE just tells you what C struct type the SV
body has (which will likely be the high-watermark of any type it has
ever had); whereas the flags tell you which subset of those fields is
actually valid at the moment.

> > I'll mention that in the RFC and point out it really does need a
> > flag - SvBOK() or somesuch?
>
> It might be possible to implement *without* a flag, as I postulated,
> using PL_Yes and PL_No, and some changes to sv_setsv_flags.
>
> (Which will need to be changed come-what-may to deal with booleans)
>
> So I think it "really does" is not correct - "might" is more accurate.

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)

I guess we /could/ allocate an empty string (or maybe be really cheeky
and point at the "\0" of the "1\0" of yes), as the SvPVX for no.

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

--
Paul "LeoNerd" Evans

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

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.