develooper 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 5, 2021 03:37
Subject:
Re: Pre-RFC: Real "boolean" SV type
Message ID:
f8bbf55b-316c-2075-e6f4-3796f5d415c3@darrenduncan.net
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.
> 


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About