Due to my ex-Perl background, this episode is very much "how much Raku fixes Perl issues" story, that's why I'm focusing on this.
Understood. But Raku borrowed a lot of ideas from many programming languages. And hopefully only the good things :-)
something you don't need to do if you code in Ruby or Python or such, where == is completely predictable
Well, I'd argue that ==is completely predictable: it does a numerical comparison. I'd argue that a "universal ==" actually does more harm than good, as it may sweep potentially important differences "under the carpet" as it were.
Raku seems to be still suffering from Perl issues here.
You seemed to have missed object hashes. In short, you can specify a constraint to be applied on the keys of a hash. The default is Str(), which is short for Str(Any), which means: accept Any object (all classes except Junction and Mu inherit from Any) object and coerce it to Str.
An example of using just integer keys, would be:
my %hash{ Int };
%hash{ 42 } = "foo"; # ok
%hash{"42"} = "bar"; # NOT ok
If you want it to coerce to an Int, you can use Int() as the type:
my %hash{ Int() };
%hash{ 42 } = "foo"; # ok
%hash{"42"} = "bar"; # also ok
Now, when it comes to using lists as a key, the situation is a little more complex. You can use a value type as a key in an object hash. An immutable Set is an example of a value type:
my $s1 = Set.new(1,2,3);
my $s2 = Set.new(3,2,1);
my %hash{Set};
%hash{ $s1 } = 42;
say %hash{ $s2 }; # 42
Now, Lists and Arrays are not value types: Arrays because they are mutable, and Lists because they can contain mutable elements:
my ($a, $b) = 42, 137; # LHS is a List with mutable elements
One approach to fix this for now, is the Tuple class. Discussions have been had about making Lists value types, but the above idiom is pretty pervasive in the Raku ecosystem and "darkpan", so not easy to fix. Perhaps a future version of Raku will allow for this to work:
my [$a,$b] = 42, 137;
to indicate a list with mutable elements, thereby freeing up () for immutable value type lists. The future will tell. Fortunately, Raku will allow such a change in syntax in a new language level: each compilation unit can indicate at which language level they wish to be compiled. This allows different semantics to be applied, while keeping interoperability between code of different language versions.
In short: the Raku Programming Language has "change" built into it, to make it a language of choice for long-living code bases. And which code base doesn't live longer than intended :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Understood. But Raku borrowed a lot of ideas from many programming languages. And hopefully only the good things :-)
Well, I'd argue that
==is completely predictable: it does a numerical comparison. I'd argue that a "universal ==" actually does more harm than good, as it may sweep potentially important differences "under the carpet" as it were.You seemed to have missed object hashes. In short, you can specify a constraint to be applied on the keys of a hash. The default is
Str(), which is short forStr(Any), which means: acceptAnyobject (all classes exceptJunctionandMuinherit fromAny) object and coerce it toStr.An example of using just integer keys, would be:
If you want it to coerce to an
Int, you can useInt()as the type:Now, when it comes to using lists as a key, the situation is a little more complex. You can use a value type as a key in an object hash. An immutable
Setis an example of a value type:Now, Lists and Arrays are not value types: Arrays because they are mutable, and Lists because they can contain mutable elements:
One approach to fix this for now, is the Tuple class. Discussions have been had about making Lists value types, but the above idiom is pretty pervasive in the Raku ecosystem and "darkpan", so not easy to fix. Perhaps a future version of Raku will allow for this to work:
to indicate a list with mutable elements, thereby freeing up
()for immutable value type lists. The future will tell. Fortunately, Raku will allow such a change in syntax in a new language level: each compilation unit can indicate at which language level they wish to be compiled. This allows different semantics to be applied, while keeping interoperability between code of different language versions.In short: the Raku Programming Language has "change" built into it, to make it a language of choice for long-living code bases. And which code base doesn't live longer than intended :-)