That helps with your own data types. But since most programs just use the default data types, it still takes more work in Perl to define a generic min function that works across strings and numbers.
Again, you are speaking of Perl 5 here;
Perl 6 has generic ordering functions already, called "before
" and "after
", and both min
are defined in terms of those. (The old string-biased cmp
was renamed to leg
.) And sort
is defined in terms of the new cmp
, so it is also generic. The least-specific ordering variants are defined in terms of comparing canonicalizations, so we can have "natural" sorting of heterogenous data.
But Perl 6 can also easily emulate the broken Ruby behavior by using the string-biased comparison operators explicitly. Philosophically, Perl 6 is going to do the right thing by default, but give the programmer the ability to supply enough type information (via either the data or the operator) for the the optimizer to do interesting things, up to and including compiling down to machine code.
(Of course, even the generic operations are allowed to do on-the-fly optimizations as long as they're pessimizable in the presence of inconsistent data. Only the semantics need be preserved--it's okay for the program to get faster or slower as the data changes in consistency. Hopefully the slowness is bounded so that you don't open your server up for denial of service attacks.)
Anyway, my point is simply that we've already thought about these things an awful lot. Please don't assume Perl 6 will fail the same way Perl 5 fails. :)