Luke Palmer writes: > The solution that springs to mind is to conform to other languages' > thought and make == polymorphically compare equality.
Nooooooooo! Please! PHP tried this and gets it very wrong indeed (searching Google Groups for posts by me to this list containing the word "PHP" should throw up a detailed explanation/rant on the issue). Having both variables and operators being untyped leads to too much guessing -- and guessing wrongly. (It's a matter of opinion whether it's the language or the programmer who guesses wrongly ...) > Thanks to context-forcing, the string/numeric distinction is still > there, at the expense of a little extra verbosity: > > +$a == +$b; # Numeric compare > ~$a == ~$b; # String compare > $a == $b; # Generic compare But what does a 'generic' compare do? While Perl 6 has typed variables, I get the impression that these are most useful for efficiency reasons (especially for array and hash elements), and that it'll still be common -- especially in simple scripts -- to continue to use Perl-5-style scalar variables. This very often leads to variables that contain textual representation of numbers. Pretty much all input from files, the keyboard, databases, and from a web forms comes in as text even if its source considers it to be numeric. Likewise, in the programmer's mind such data is numeric. Doing a string comparison because it currently happens to be stored as a string is far too confusing. The other reason for not having unary C<+> and C<~> to force numeric or string context is the reason that Larry gave when we were discussing the bitwise operators. Somebody suggested that a single operator could do for both numeric and character operations, using these symbols on the operands to resolve ambiguities. Larry rejected the idea, on the grounds that operands can be arbitrarily complex expressions, and that can leave the C<+> or C<~> for the left operand a considerable distance from the operator on which it has an effect. Smylers
