Andy Wardley wrote: > Quoted from "Seven Deadly Sins of Introductory Programming Language > Design" [1] by Linda McIver and Damian Conway: > > over one thousand novice programming students ...: > > "the quick brown fox" + "jumps over the lazy dog" > > ... they believed that the + should concatenate the two strings. > > Makes perfect sense to me.
Makes sense in a language where variables are typed, because the type of operation can use the type of the variables. Having types in neither variables nor operators causes confusion. > Can we overload + in Perl 6 to work as both numeric addition and > string concatenation, depending on the type of the operand on the > left? > > I realise the answer is "probably not", given the number/string > ambiguity of Perl variables: > > my $a = 123; > my $b = 456; > $a + $b; # 579 or 123456? Indeed. And even more so with: my $a = 123; my $b = '456'; print $a + $b; You suggest using the type of the left operand. So now when wanting to perform addition the order of the operands can matter: print $b + $a; I realize that by definition the operand order is significant in concatenation. (Some argue that this alone is sufficient reason for not overloading C<+> for concatenation in any language.) But having the order of operands determine which of addition or concatenation takes place strikes me as very fragile. There are other languages which have attempted having both variables and operators without types: * Basic has traditionally had typed variables and C<+> for both addition and concatenation. Microsoft 'Visual Basic' introduced 'variant# variables (in, I think, version 3) of no particular type. To avoid the addition or concat problem they added the C<&> operator to always mean concatenation (deprecating C<+> for concatenation, but continuing to allow it where unambiguous for backwards compatibility). * I think JavaScript does what you're suggesting. I don't really know JavaScript, but recently while trying to hack on code I didn't understand I could I could access a previous array element with: options[i - 1] but, because C<i> was a string, this didn't give the following element: options[i + 1] // multiplies by 10, _then_ adds one! and ended up with: options[i - 0 + 1] // eurgh! Please let's not go there with Perl. * PHP has separate concatenation and addition operators, but tries to get away with a single untyped equality operator. I posted a message to this list a couple of weeks ago demonstrating some of the ways this fails. While I think that McIvery and Conway are absolutely right for the context in which they made the above observations, I don't think that they necessarily apply to Perl: * Data read in to Perl tends to arrive as strings. This applies whether reading from the keyboard, getting values from a form on a webpage, reading from a file, or retrieving records from a database. Therefore you are very likely to end up with numeric data just happening to be stored as a string initially. My example above: my $b = '456'; is obviously contrived, but numbers stored as strings are common. (See also previous PHP equality operator rant.) This potential confusion doesn't occur in C++, therefore using C<+> for concatenation is much more sensible. * The paper points out what C++ actually does when C<+> is used with a couple of strings (trying to add the addresses of the first character of each string) is completely useless, therefore the syntax may as well be redeployed in a fruitful way. Perl already does something useful with this syntax. Some beginners may use C<+> hoping to get concatenation, but I think on discovering that C<+> has tried to add their strings mathematically they will be able to understand this behaviour much more so than the C++ behaviour. * The paper is discussing what makes a good language to use when trying to teach programming. The points made are not what makes a language easy to learn per se, but what helps when trying to use a language as the tool for teaching programming to complete beginners, those who don't know anything at all about programming and are struggling to come to terms with its concepts. I don't think use in teaching programming is a primary aim of Perl 6. (Or, another way round, I think that making Perl 6 a great language for teaching programming would make it too restrictive for the rest of us.) * If somebody uses C<+> in an attempt to concatenate two strings, chances are that at least one of those strings isn't numeric. In this case Perl uses a value of zero and displays a warning. In other words, it's very often possible to identify an attempted abuse of C<+> because it's being used somewhere that it doesn't make sense. If C<+> did double duty for concatenation then it would always make some sort of sense. People would still write programs that did the wrong thing, but there could no longer be a warning message pointing this out because Perl wouldn't be able to notice. Arguably the warning (or related diagnostic message) in this case could be improved, for example by explicitly stating that C<+> only does arithmetic and that if concatenation is desired then C<~> (or whatever it is) should be used instead. Not being able to use C<+> for concatenation may trip up some people learning Perl some of the time, but I reckon it's a fairly easy hurdle to get over and that it isn't the main cause of trouble people have with learning Perl. > Another option: could we quote operators to indicate string context? > > $a "+" $b Hmmm ... print $a "+" "+" "+" $b "+" "=" $a + $b; print $a "+" qq("+") "+" $b "+" "=" $a "+" $b; print "$a+$b=" "+" $a + $b; print qq($a"+"$b=) "+" $a "+" $b; print "$a+$b=$($a + $b)"; print qq($a"+"$b=$($a "+" $b)); I don't think I'm so keen on that idea. Smylers