Luke Palmer writes: : Hello everyone. : : I just subscribed to this list. My name's Luke and I'm a perl : devotee. And I'm starting out with a bang. Here goes: : : I have just read through exegesis 3, and I found the bit about : defining your own new operators (eg. operator:*#@&) to be a little : strange. Not confusing, but esoteric and random. What functionality : does this provide to the language other than "It's cool."
In evolutionary terms, the ability to be more adaptive. : I think, if anything, it would make things more confusing. Suppose a : module that implemented, say, a vector (disregarding that this isn't : really needed) provided a new operator .prod for dot product. What : would happen in the following case: : : use Vector; : $v = new Vector; : $v.prod $j; : : Does that last statement mean $v.prod($j), or ($v) .prod ($j)? Not to : mention, how is the user supposed to know that she can't say : $v.prod($j)? Doubtless such a token would be frowned upon. Good reason to use a Unicode character instead, to avoid conflict with builtins. Gee, maybe we should use U+22C5, "DOT OPERATOR". : What about the example in the exegesis: 'operator:*#@&'? Take the : following code: : : $f *#@& : $g; : : What does this mean? Does this mean $f * $g with #@& as a comment, or : does it mean $f *#@& $g? The longest-token rule means it would be interpreted as the latter. We already have tokens that contain # and are not interpreted as comments, things like $#foo and s#foo#bar#; : But anyway, those are just language semantics : that could be worked out one way or another. The big confusion lies in : documentation and memory (human memory, that is). When your reading : through documentation for this Vector class, which would you rather : see? : : Vector provides an operator `.prod' for computing dot : products. It has the same precedence as the Perl binary * : operator. It also provides the xprod operator which has the same : precedence as Perl's binary + operator. : : --or-- : : Vector provides two methods, dot and cross, which compute the : dot product and the cross product, respectively, on their : arguments. : : The latter has significantly less to remember, using the : ever-so-familiar method, rather than entering two new operators with : precedences and all into your knowledge base. Hmm, by that argument, all mathematical formulas ought to have nothing but words in them. But there are also a great deal of ever-so-familiar items from math culture (well, ever-so-familiar to mathematicians), and many of mathematicians would rather see the punctuation they're familiar with. : Also I think that these new operators would add a new level of : obfuscation to the language when it's not intended to be : obfuscated. When one encounters the *#@& operator, one must consult : the documentation for that operator, while method names are forced (at : least for people with any good taste) to make a small amount of sense. And there you've put your finger on it. Cultural tastes will have to be enforced in either case. I'm certainly going to quarrel with any one who wants to overload << to be the output operator. And Unicode operators will be culturally unacceptable as long as it's difficult to enter Unicode on the terminal. But I don't expect that to remain the case forever, and I want Perl to be a good language for 20 years from now. : Not to mention the extra strain on the lexer, not that it matters : much. If strain on the lexer were a design criterion, I blew it long ago. :-) : But in general, I suggest that the whole roll-your-own operator thing : be stripped from Perl 6. Not completely, however. I like the idea of : overloading existing operators, which has long been a part of the : language. That kind of limitation forces people to overload << for output. : I also kind of like the idea of defining infix : operators. But I think that would come back to the whole complication : with precedences again, which I don't find much elegance in. I think that's a non-issue. The definition will say, "This is to be thought of as a kind multiplicative operator," and people will know just how it behaves with respect to precedence. We don't necessarily have to grow the precedence table to deal with new operators. : In summary, roll-your-own operators seem to be a contrived attempt at : being revolutionary, without providing much practicality. Depends on how you look at it. It's more to enable something revolutionary later that we haven't thought of yet. : Not to bash them or anything :-P Bash away. It's all grist for the rock tumbler. :-) Larry
