develooper Front page | perl.perl5.porters | Postings from March 2022

Re: Pre-RFC: builtin:: functions for detecting numbers vs strings

Thread Previous | Thread Next
Darren Duncan
March 12, 2022 03:20
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On 2022-03-11 3:34 p.m., Yuki Kimoto wrote:
> Darren, Dan, Yves
> Thank you for telling me the difference between a variable and a value.
> I have another question.
> If the two "created_as_number" and "is_number" functions existed, what cases 
> would the two functions return the different results?

I have no idea, because I am not advocating for any such functions.

What I'm advocating for, loosely speaking, is THESE two functions:

* is_canonically_a_number - This is true when someone wants to deterministically 
categorize some given Perl value into exactly 1 best container, either number or 
string or boolean or whatever, for example, to turn it into JSON that can 
round-trip losslessly.  This is mutually exclusive with is_canonically_a_boolean 
or is_canonically_a_string etc, only one ever returns true for a given value.

* can_be_used_as_number - This is true when someone wants to treat some Perl 
value as a number, say to add one to it, and wants to know if Perl will do that 
cleanly.  This is not mutually exclusive with can_be_used_as_a_boolean or 
can_be_used_as_a_string, often the same values several of those will return true 

The latter is what typical Perl users care about, the former is what important 
niches like serializers care about.

The created_as_number being discussed appears to provide the 
is_canonically_a_number concept, but I'm not sure about edge cases.  These are 
all hypothetical anyway.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About