|Do you know where your variables are?|
Today a proposal came up on the Perl 5 Porters mailing list to have a new pragma that would replace the dereference and method call operator (->), with the dot (.). Since this is now used as the concatenation operator, for the purpose of concatenation the tilde (~) would be used. (It is now used as the one’s complement operator, and would still mean that in unary contexts, but between two terms would mean to concatenate.)
There are two pretty good reasons for this. First, the dot is easier to type than the ->, and since this is one of the most used operators in all of Perl, it would save a lot of typing (and saved characters, the necessity for wrapped lines, etc.). Second, many other common computer languages use the dot as the object method call, so this would ease learning of Perl by those familiar with other languages (and, I suppose, learning of other languages by people familiar with Perl).
I’m not sure this is the right thing to do, for a couple of reasons. One of the reasons is purely semantic. In Western written natural languages, the dot is normally used to end a sentence. That’s the opposite meaning of the dot here: it indicates that the part after the dot is a qualification or function dependent on the part before the dot. If any single character in ASCII indicates that, it would be the colon (:), a character which, on its own, is terribly underutilized in Perl, introducing the third part of the conditional operator (?:).
But the other reason is the joint use of tilde as binary concatenation operator and unary one’s-complement operator. These are two uses of the same character that have absolutely nothing to do with each other. The perl interpreter will, no doubt, have no trouble determining whether, in a particular spot, the use of the tilde is unary or binary. But will that be as easy for people to figure out?
I hesitate to go further, because I’m afraid it will mark me as un-perly and I’ll be exiled, forced to live in a world that uses significant whitespace. But I think the tendency of Perl to use lots of different ASCII punctuation in lots of different ways can be confusing, especially when white space isn’t always required between terms. Is that “&” the bitwise and operator or the sigil for a code reference? Does that dot mean concatenation, or is it the decimal point? Is the three-dot combination ... the flip-flop operator or the “yada yada yada” operator indicating that more is to be written later? Is that octothorpe (#, confusingly enough sometimes called the hash) introducing a comment or is it part of the $# array count symbol?
And, of course, punctuation variables add more ambiguity. I know that perl generally can figure this out, although the several entries in perldiag beginning “Ambiguous use of…” makes me wonder. But people often have more difficulty. (In spoken natural language, one can always inquire of the speaker to clarify ambiguity; not so here. Perhaps natural languages are different than computer languages? Can I say that?)
It’s too late now to go back and give Perl a set of clear, unambiguous operators.
(In my dreams I imagine a Perl where punctuation variables are replaced by variables beginning with control characters. Where terms made of punctuation would always be separated from other punctuation terms by whitespace [so +=- would be a trigraph, not an addition-assignment followed by a unary minus]. Where . is always the decimal point; where & and % are either sigils or operators but not both. Then I start thinking about whether @fred could be the same as @$fred, and &fred the same as &$fred, and if so whether we really need @fred and &fred at all, and then whether we need sigils at all, and then I wake up in a cold sweat.)
But, although perhaps my opinion is colored by a deep unperliness, I don’t think adding more ambiguity is the right direction.
Just to be clear, I don't actually program in much anything except Perl (and, shudder, Applescript)... so I don't think I can be accused of being corrupted by the outside. Naïve about other languages, certainly.