Perl 5.10.1 Smartmatch Num ~~ Numish

T

tuser

In Perl 6, I find the following about smart matching:

http://perlcabal.org/syn/S03.html#Smart_matching

$_ X Type of Match Implied Match if (given $_)
====== ===== ===================== ===================
[...]
Any Num numeric equality +$_ == X
Any Str string equality ~$_ eq X
[...]
====== ===== ===================== ===================

That means in Perl 6:
=====================
case #A1: 2 ~~ 2.0 translates into 2 == 2.0 ==> true
case #A2: 2 ~~ '2.0' translates into 2 eq '2.0' ==> false



In perl 5.10.1, I find the following about smart matching:

http://search.cpan.org/~dapm/perl-5.10.1-RC1/pod/perlsyn.pod#Smart_matching_in_detail

$a $b Type of Match Implied Matching Code
====== ===== ===================== =============
[...]
Any Num numeric equality $a == $b
Num numish[4] numeric equality $a == $b
[...]
Any Any string equality $a eq $b
====== ===== ===================== =============
[4] either a real number, or a string that looks like a number

That means in Perl 5.10.1:
==========================
case #B1: 2 ~~ 2.0 translates into 2 == 2.0 ==> true
case #B2: 2 ~~ '2.0' translates into 2 == '2.0' ==> true

The question I have is:
Why is 2 ~~ '2.0' false in Perl 6 (case #A2), whereas the identical
expression in Perl 5.10.1 (case #B2) is true ?

Or in other words:
Why is there a rule in Perl 5.10.1 ("Num numish numeric equality"),
where there is no equivalent in Perl 6 ?
 
I

Ilya Zakharevich

For a proper answer you would have to ask p5p, but I would guess it's so
that something like

my $x = 3;
print $x;
"3.0" ~~ $x;

does what is expected. The 'print' statement has converted $x into a
dualvar, and there is no way to tell which part (string or number) came
'first',

I hope there is. At least there was a way - after I "regularized"
Perl handling of numbers.

Obviously, there MUST be a way - otherwise one would not be able to
"correctly" translate a 2-headed value into a 3-headed one... (Ask if
one wants to know more details. ;-)

Hope this helps,
Ilya
 
I

Ilya Zakharevich

Now it appears to do the IV conversion straight away (to preserve the
precision):

PV --> NV is only one of 6 possible pathways; doing *this one*
straight away is not going to be a waste of space, sine PVNV has an IV
slot anyway; however, the others might have serious effects on memory
usage...

Yours,
Ilya
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top