Front page | perl.perl5.porters |
Postings from March 2022
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Thread Previous
|
Thread Next
From:
Dan Book
Date:
March 9, 2022 16:18
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
CABMkAVXNd8qQ2R6ubjnS5xNDs1YizrCBqMVVGic9zJD==xVsZA@mail.gmail.com
On Wed, Mar 9, 2022 at 10:55 AM Salvador Fandiño <sfandino@gmail.com> wrote:
>
> On 9/3/22 15:30, demerphq wrote:
> >
> >> IMO, the problem here is that we are still keeping the old mindset where
> >> perls scalars where transformed from one type to the other and we
> >> couldn't tell which one was the former one.
> >>
> >> The thing is that now we know the former type, so, I think we should
> >> stop thinking about the-scalar-that-was-created-as-a-number and instead
> >> start considering it the-scalar-that-is-a-number.
> >>
> >>
> >> The fact that Perl can internally keep other representations of the
> >> scalar (for instance, a string) doesn't change the fact that the scalar
> >> *is* a number.
> > I think you are missing the point though. "created as a number" and
> > "is a number" aren't the same thing.
>
> Yeah, and that is exactly my point, they *can* be the same, it is just a
> matter of switching your mental model!!!
>
> Until now, perl was not able to keep scalar types. For instance, after...
>
> $a = 9; say "hello $a";
>
> ... $a was both an integer and a string. There was no way to
> differentiate between the creation type and the ones acquired along the
> scalar life.
>
> But *now*, we can differentiate then, we can decide that $a is a number.
> Even if there is a string representation attached to the SV representing
> it, we can still consider it is a number.
>
> Because otherwise, what value do we get by thinking that the resulting
> $a above, is a number and a string? nothing? just an internal detail?
> IMO that is a useless model.
>
>
> > Perl defines that "7" and 7 are both equivalent in almost every
> > regard,
>
> And that doesn't change, different types with transparent conversion
> when needed. They keep being equivalent except, as you say, in the
> places where they are not:
>
>
> > the few places they might not be the dev is expected to
> > disambiguate, eg logical operators like ^ | & care, nothing else in
> > perl does, and in those cases the dev should be specifying which
> > behavior they want by doing 0+$x | 0+$y or "$x" | "$y". Because to
> > perl both "are" the number seven and both "are" the string "7".
>
> So, what you are saying is that the only safe way to use those operators
> is to force an explicit coercion every time they are used?
>
> It is better to have the current semantics which are a minefield?
>
> $a = 7; $b = 8;
>
> say("a: $a, b: $b") if $debug;
>
> $c = $a | $b;
>
>
> $a = "7a"; $b = "a7";
>
> $a++; $b++;
>
>
> > But "7" is created as a string, and 7 is created as a number.
> >
> > We dont want people to think that somehow 7 is less of a number than
> > "7" because to Perl they should be the same thing.
>
> Again, that is what you decide your mental model to be. In most cases,
> you want 7 and "7" to be equivalent, but not always.
>
> So you can see it as...
>
> 1) they are the same except in some cases.
>
> 2) they are different things but perl converts transparently between
> then as needed.
>
> Now you should consider if (1) is the best and easiest model and the one
> you want to promote or if it is just that you like it because you are
> used to it.
>
>
> > However when we interoperate with other systems /they/ make a
> > distinction between 7 and "7". And using the wrong one can confuse
> > them. So we want a way where serialization layers can know that a
> > given $var should be represented as an unquoted number or as a string
> > when talking to those external systems. The reason the name is chosen
> > to be the cumbersome "created_as_number" is that we don't /want/ code
> > to be written that checks these things very often. These functions
> > should be extremely rare. That is also why we want to have a
> > looks_like_number() as well, because that side-steps the "is a"
> > question and changes it to a "can be used as a" question. Its almost
> > at the level that if you use one of these functions and you are not
> > writing a serialization module then you are basically doing something
> > wrong.
> >
> > Maybe it would even be better to call these functions
> > "serialize_as_number" instead of "created_as_number" because that
> > would make clear the specialist use case.
>
>
> It is not just serialization, there are far more use cases where being
> able to tell if something is/was-created a number could be useful.
>
> For instance, having a sub that behaves differently when passed a string
> or a number (some may find that very unperlish, well, to those I would
> say I find very unperlish not letting the programmer decide how to solve
> his problem in the best way).
>
> Another common case, very similar to serialization, is interacting with
> C or C++ libraries. For instance, one offering some "foo_number" and
> "foo_string" functions that you want to wrap as a unique "foo" sub.
>
Please continue this discussion in the threads about type systems and not
here. That is not the purpose of the proposed functions.
-Dan
Thread Previous
|
Thread Next