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

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

Thread Previous | Thread Next
March 9, 2022 11:21
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Wed, 9 Mar 2022 at 10:10, Salvador Fandiño <> wrote:
> On 8/3/22 17:25, Karl Williamson wrote:
> > On 3/8/22 07:38, Graham Knop wrote:
> >> On Fri, Mar 4, 2022 at 4:29 PM Paul "LeoNerd" Evans
> >> <> wrote:
> >>>
> >>> After further discussion with PSC, we'd like to keep moving this
> >>> forward. There's still time to add new functions to builtin:: in time
> >>> for 5.36, and it would be nice to get these in.
> >>>
> >>> We agree that they should not be named "isnumber" and "isstring",
> >>> mostly because of your concerns about leading people to think they do
> >>> something that they don't.
> >>>
> >>> I'd like to suggest you write up an RFC on this request, perhaps
> >>> beginning with the names
> >>>
> >>>    builtin::was_originally_number
> >>>    builtin::was_originally_string
> >>>
> >>> They're sufficiently long and unwieldy as to mildly discourage people
> >>> from using them except when absolutely necessary (read: on JSON
> >>> serialisers and similar), and the name itself doesn't suggest it tells
> >>> you current information about the actual type of a value, merely tells
> >>> you the history on how it started.
> >>
> >> I've created an RFC PR:
> >>
> >> In the RFC, I'm using the names builtin::created_as_number and
> >> builtin::created_as_string. Justification is included in the RFC, but
> >> I think these better match what we want their return values to
> >> represent. And I personally, was_originally_number feels really
> >> awkward as a function name. The names could still be changed of
> >> course; I'm not overly attached to what I've chosen.
> >
> > I think "created_as..." are better than previous suggestions
> It has just occurred to me that we may be missing the point focusing in
> that it-was-created-as-a-whatever thing too much.

No, that is very much the point. Serializers, especially JSON need to
know this or they simply do the wrong thing.

> If a scalar was created as, say, a number, it keeps being a number. That
> perl is able to transparently convert that value into something else
> when needed and cache the result, doesn't change the fact that it is
> still a number.

Right. But previously we couldn't tell if the number started off as a
string or a number.

>  From a functional point of view, I think that was is needed is a set of
> functions to check the type of a scalar and another set of functions (a
> la looks_like_number) to check whether it can be converted into
> something else:
>    builtin::isa_number
>    builtin::looks_like_number
>    etc.

I dont really follow what "isa_number" is compared to
"looks_like_number". Is "isa_number" meant to to be the same as
"created_as_number" from this proposal?

> One important point here is that neither "isa_number", neither
> "looks_like_number" are influenced by the private type flags (or the
> scalar history, which is an uninteresting thing, right?):
>    $a = "7";
>    say isa_number($a), looks_like_number($a);
>    $b = $a+1;
>    say isa_number($a), looks_like_number($a); # same results

I dont get what you want here. The standard definition of
looks_like_number() would return the same thing for both lines. I am
not sure what isa_number is supposed to do, but if its the same as
created_as_number() then it would too.  Eg,  say would output FALSE,
TRUE both times. (For some printed definition of FALSE and TRUE).


perl -Mre=debug -e "/just|another|perl|hacker/"

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