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

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

Thread Previous | Thread Next
Dan Book
March 14, 2022 17:53
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Mon, Mar 14, 2022 at 1:51 PM Darren Duncan <>

> 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
> etc.
> 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?

We are not discussing classification of values. Again, please bring that up
in threads about typing and not here.


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