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 14, 2022 17:51
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
Okay, I have even BETTER name proposals:

- is_classified_as_number()
- is_classified_as_string()
- is_classified_as_boolean()

See also for precedent.

The POINT here, as I see it, is we want to be able to take any given Perl value 
and deterministically classify it into EXACTLY ONE mutually exclusive type.

This is all about, we have a value, sort it between various choices where it 
fits best.

It doesn't exactly matter how we got to that point as long as a clear decision 
is made. This tends to correlate with decisions made on creation or use but 
using "classify" avoids implying things beyond the use case of sorting.

As for "canon", I agree it is much less linguistically clear as to why I chose 
that, but what I was going for was as in "canonical works" or "authorized; 
recognized; accepted", the idea that we made an official position on what 
criteria of a Perl value sorts it as a number versus a string etc.

But even if I still think "canon" makes sense, I put forth that "classify" gets 
the point across much better.

I should say however, that my wider proposal is actually more of a hierarchy 
than a strict mutually exclusive decision.

Loosely speaking, this for example:

- is_classified_as_undef()
- is_classified_as_boolean()
- is_classified_as_number()
   - is_classified_as_integer()
   - is_classified_as_float() or is_classified_as_fraction()
- is_classified_as_string()
   - is_classified_as_text()
   - is_classified_as_blob()
- is_classified_as_array()
- is_classified_as_hash()
- is_classified_as_object() in the Corinna sense

So all leaves of the hierarchy are mutually exclusive and every Perl value is a 
member of exactly 1 leaf, but when leaves have parent nodes, then when a value 
is a member of a child it is also a member of a parent.

Critically this also means we can and should be able to have also:

- most_specific_classified_type_of()

... or similarly named which results in a STRING like 
"boolean"/"integer"/"float"/etc that one can then use in a given-when expression 

Now I realize the subtypes of "string" here may be more complicated since in 
practice the same representations may overlap, so resolving that this time could 
be skipped if there isn't a good solution at this time, while still keeping the 
rest of what I said, and in fact the hierarchy approach intentionally gives us 
room to grow and evolve.

The integer vs float thing we should be able to do right away though.

Ovid and others, what do you think of that?

-- Darren Duncan

On 2022-03-14 3:53 a.m., Ovid via perl5-porters wrote:
> On Monday, 14 March 2022, 06:37:26 CET, Darren Duncan <> wrote:
>> I made good name proposals already:
>>   - is_canonically_a_number()
>>   - is_canonically_a_string()
>>   - is_canonically_a_boolean()
> Naming is hard. Very hard. It's even harder when many people are non-native English speakers. I'm a native English speaker and a writer and it wasn't clear to me that "canonically" is appropriate here. I hit ( and not a single definition appears to fit the meaning of this as I understand it. You could check other dictionaries, such as Merriam-Webster, Collins, etc., and again, canonically doesn't quite seem to fit (Collins seem the closest to what you're saying
> The most accurate description I can think of is something like:
>      was_initialized_as_number()
> But we don't do past-tense, so perhaps the slightly awkward:
>      is_initialized_as_number()
> I *think* this is:
> * Accurate
> * Non-native speakers will already know "Initialized"
> * Long and cumbersome enough to be annoying :(
> I'd welcome something better, but I can't think of anything. (I also thought "is_declared_as_number()", but that feels subtly wrong to me)
> Best,
> Ovid

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