|
Re^2: Reason for this discrepancy with scalar?
by choroba (Cardinal) on Mar 14, 2024 at 09:13 UTC
|
This doesn't happen in 5.26.1 (I haven't tested any other old versions), where the our and my behave the same way.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l] |
|
|
perl -MDevel::Peek -e 'Dump(!!0)'
SV = PVNV(0x1838140) at 0x18363f8
REFCNT = 2147483647
FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0x5e6583 "" [BOOL PL_No]
CUR = 0
LEN = 0
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l]
[select] |
|
|
I think this could be related to https://github.com/Perl/perl5/issues/19378.
As of a couple years ago I stopped checking for equivalence to &PL_sv_yes in my XS files.
Instead I now use SvTRUE_nomg_NN(sv) (and !SvTRUE_nomg_NN(sv) for FALSE).
Nice work choroba.
I think you've earned the right to file the bug report - or the PR, if you prefer ;-)
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l]
[select] |
Re^2: Reason for this discrepancy with scalar?
by dave_the_m (Monsignor) on Mar 14, 2024 at 15:38 UTC
|
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
Dave. | [reply]
[d/l] |
|
|
Thanks!
2 questions tho:
- > 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.
- > 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?
| [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] |
|
|
|
|
|
Re^2: Reason for this discrepancy with scalar?
by kikuchiyo (Hermit) on Mar 14, 2024 at 09:24 UTC
|
| [reply] |