Every language does 1 == 1.0 numerically, so Ruby isn't unusual here, Raku's eqv is the weird one out.
But mainly if you have a bunch of numbers of different types in Ruby, it is immediately obvious which number is what type, as they all print as different:
And I think pretty much all other languages where there are ints and floats and other types. If there are multiple number types, they appear as different.
In Raku they appear identical as 1, while eqv treats them as different. I don't think this is a good design.
Well, "print as" is also a complex topic :) In Raku, the .gist method (which is used by say etc) prints both 1.0 and 1 as 1, but the .raku method (which prints the debug representation) prints 1.0 and 1. This feels correct to me – again, maybe because of time spent with Rust, which makes exactly the same choice.
Again with Rust, not only does 1 == 1.0 not return true, it doesn't even compile (without an explicit cast). So, from a certain point of view, Raku's behavior represents something of a compromise between the dynamic behavior of a language like Ruby and the type-system-enforced guarantees of a more static language.
And, really, Raku falls somewhere between those two extremes quite frequently. You noted Raku's clear Perl legacy, and that's definitely a big part of the linage. But Raku's DNA also owes a surprisingly large amount to Haskell due to a large number of Haskellers involved in the early design process (or so I've heard/read – I wasn't involved that early).
Every language does 1 == 1.0 numerically, so Ruby isn't unusual here, Raku's eqv is the weird one out.
But mainly if you have a bunch of numbers of different types in Ruby, it is immediately obvious which number is what type, as they all print as different:
Same with Python:
And I think pretty much all other languages where there are ints and floats and other types. If there are multiple number types, they appear as different.
In Raku they appear identical as 1, while eqv treats them as different. I don't think this is a good design.
Well, "print as" is also a complex topic :) In Raku, the
.gistmethod (which is used bysayetc) prints both1.0and1as1, but the.rakumethod (which prints the debug representation) prints1.0and1. This feels correct to me – again, maybe because of time spent with Rust, which makes exactly the same choice.Oh, and re:
Again with Rust, not only does
1 == 1.0not return true, it doesn't even compile (without an explicit cast). So, from a certain point of view, Raku's behavior represents something of a compromise between the dynamic behavior of a language like Ruby and the type-system-enforced guarantees of a more static language.And, really, Raku falls somewhere between those two extremes quite frequently. You noted Raku's clear Perl legacy, and that's definitely a big part of the linage. But Raku's DNA also owes a surprisingly large amount to Haskell due to a large number of Haskellers involved in the early design process (or so I've heard/read – I wasn't involved that early).
Haskell makes the same choices as Ruby and Python (and pretty much every other language):