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

The ops used for looking up an array in scalar context are different for pad vars and for global vars (pp_padav vs pp_rv2av). One of those ops was optimised by me such that, when returning a zero value, it returned the special SV PL_sv_zero rather than setting a PADTMP SV to zero and then returning that. I don't remember offhand why the other op wasn't or couldn't be similarly optimised. Apart from esoteric uses (such as inspecting the internals with Peek()), the two different return values should generally have the same behaviour. Both evaluate to 0 in numeric context and to "0" in string context. Just with different overheads. Serializers tend to struggle with such things, but that's a general problem with perl's polymorphic internal representations of values. For example, for a hypothetical serializer function, you typically get this behaviour: 
    my $x = 0;
    serialize($x); # outputs an integer
    say "x=$x";    # $x now has both valid int and string representati
+ons
    serialize($x); # outputs a string

[download]

Dave.

Replies are listed 'Best First'.
Re^3: Reason for this discrepancy with scalar?
by LanX (Saint) on Mar 15, 2024 at 12:27 UTC
    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

[reply]
      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]

In Section Seekers of Perl Wisdom