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

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

Thread Previous | Thread Next
February 24, 2022 09:41
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
On Thu, 24 Feb 2022 at 06:54, Darren Duncan <> wrote:

> On 2022-02-23 9:33 p.m., Dan Book wrote:
> > On Thu, Feb 24, 2022 at 12:30 AM Darren Duncan wrote:
> >     I can completely get behind the idea of properly naming the
> functions so that
> >     their names correspond to their actual meanings.  Mainly what I care
> about is
> >     that the functions exist at all, whatever they are called.
> >
> >     On a related note, the original proposed names were for parity with
> isbool().
> >     So if the new ones are going to have names like
> was_input_as_number(), then
> >     isbool() should similarly be renamed to was_input_as_boolean() or
> such.
> >     Consistency is important.
> >
> > They don't need to be consistent since they do different things. isbool
> returns
> > true for only two scalar values which can only ever be booleans. Numbers
> and
> > strings in general however can become also numbers or strings during
> their
> > lifetime, regardless how they started.
> "Can only ever"?  I had the impression that scalars which started out as
> booleans can always be used as either numbers or strings.  Or are you
> saying
> that using a number as a string or vice-versa makes an internal
> representation
> change for caching purposes (storing both the C int or float plus the C
> string
> etc) that doesn't happen with the scalars that start out as booleans?

On the contrary, a bool false *starts* out being a dual var (that is a PVNV
which has a variadic string slot compared to its IV/NV slot) , and a bool
true starts out as a fully fleshed PVNV. The magic that makes them bools is
that their PV buffer is shared amongst all instances, and is at a well
known address (that of the pvs stored in PL_sv_yes and PL_sv_no).

It also means the rule that Graham mentioned earlier is wrong, it is not
"if the POK flag is set then it started out life as a string", it is "If
the POK flag is set and the PV buffer is not the same as the PV buffer in
PL_sv_yes and PL_sv_no then it is a string".

$ ./perl -Ilib -MDevel::Peek -e'Dump(!0); Dump(!1);'
SV = PVNV(0x55b6a3e11158) at 0x55b6a3e0f388
  REFCNT = 997
  IV = 1
  NV = 1
  PV = 0x55b6a29ff0f3 "1" [BOOL PL_Yes]
  CUR = 1
  LEN = 0
SV = PVNV(0x55b6a3e11138) at 0x55b6a3e0f3b8
  REFCNT = 1000
  IV = 0
  NV = 0
  PV = 0x55b6a29ff0f5 "" [BOOL PL_No]
  CUR = 0
  LEN = 0

You can answer these questions yourself btw, just use Devel::Peek::Dump and
look at the output.

In older perls it is similar but the concept of a "bool' having a shared PV
slot with PL_sv_yes and PL_sv_no is not implemented. In some rare cases in
older unthreaded perls you can "see" a true PL_sv_yes or PL_sv_no. In
threaded perls it was always a copy. (You can tell by looking at the


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