in reply to Re^2: Reason for this discrepancy with scalar?
in thread Reason for this discrepancy with scalar?

Thanks!

2 questions tho:

  1. > looking up an array in scalar context

    Yeah, but I was under the impression the patch was supposed to improve Boolean context. And several sources claim that Perl is internally subdividing scalar context into Boolean, string and (various) numeric contexts.

  2. > Serializers tend to struggle with such things

    What some programmers seem to expect is that the initial type (i.e. at time of assignment) is preserved.

    Was it ever discussed to add a flag "initial_type" to scalar vars, which ...

    • is updated with each assignment only
    • could be queried via a Scalar::Util::initial_type() function
    • update serializer to use initial_type()

    ...???

    And if it was already discussed, what are the reasons against?

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

  • Comment on Re^3: Reason for this discrepancy with scalar?

Replies are listed 'Best First'.
Re^4: Reason for this discrepancy with scalar?
by dave_the_m (Monsignor) on Mar 15, 2024 at 22:28 UTC
    Yeah, but I was under the impression the patch was supposed to improve Boolean context. And several sources claim that Perl is internally subdividing scalar context into Boolean, string and (various) numeric contexts.
    At the language level, Perl doesn't formally divide scalar contexts into sub-contexts. But behind the scenes, such distinctions are sometimes used for optimisation purposes. For example, when length() is applied to to a utf8 string and length() is in boolean context, it's cheaper to just return an indication of whether the length is non-zero or not, rather than having to do a potentially expensive bytes-to-chars conversion behind the scenes to calculate an accurate integer length value.

    In the case of PADSV op, in scalar (but not boolean) context, to return an actual integer value, it has to create a temporary SV, set it to the size of the array, and return it. This is quite expensive, and so for the special but common case of the array being empty, it's cheaper to return the immortal PL_sv_zero SV. Which should make no difference at the language level.

    Was it ever discussed to add a flag "initial_type" to scalar vars
    It's been discussed from time to time. It's hard: there aren't many spare flags, and there are many places in the src where initial values may get set, and even more once XS code is taken into account. And even the very definition of initial value is up for debate. For example, in /(\d+)/ && $i = $1, should $i's initial value be regarded as a string or integer?

    Dave.

[reply]
[d/l]
      Thanks for the detailed and enlightening reply! :)

      > should $i's initial value be regarded as a string or integer?

      Ok I get your point.

      I'd say regexes are string operations.

      And parsing the capture group for occurrences of \d might be too complicated. Especially because (\d\.\d) is a float.

      Anyway does Perl really set the IV slot in your example?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
[d/l]
[select]
        Anyway does Perl really set the IV slot in your example?
        No, perl regards it as a pure string at that point.

        It's just an example of what perl regards as an initial type and what we think of as a "useful" initial type not always coinciding. So I'm sceptical that putting in effort to make perl record the initial type is going to help serialisation as much as people expect.

        Dave.

[reply]

In Section Seekers of Perl Wisdom