Fully agreed. Other places where the context model has not been applied consistently:
- The reverse operator does either string or list reversal depending on the calling context. Doesn't fit the pattern.
- infix x does either string or list repetition, not by imposing context or by being sensitive to the outer context, but by introspecting the left-hand side. WRONG.
Perl 6 has addressed those points, thought it took quite some time for some of them.
| [reply]
[d/l] |
Just read S03: Changes to Perl operators. Impressive consistency improvements. I like the new x (string multiply) versus xx (list multiply) distinction.
I suppose the vast number of operators that Perl supports, compared to other languages, is made possible by sigils; that is, languages without sigils couldn't so easily use x or xx as an operator. BTW, I was surprised to learn that the string multiply operator is commutative in Python (that is, "X"*3 and 3*"X" both produce "XXX"), which looks a bit odd to me (you learn these things playing golf you see ;-).
I also revisited the lovingly crafted Periodic Table of the Operators -- which clarifies why Perl is sometimes referred to as an "operator-oriented language".
| [reply]
[d/l]
[select] |
I suppose the vast number of operators that Perl supports, compared to other languages, is made possible by sigils; that is, languages without sigils couldn't so easily use x or xx as an operator.
Technically that's not quite correct. The really interesting property that makes that possible is predictive parsing. That is, the Perl parsers always knows whether to expect an infix operator or something termish (a prefix operator or a term, like for example a number, variable, subroutine call etc.).
Even in an imaginary Perl without sigils, the following code could be parsed unambiguously:
# imaginary sigilless Perl
my x = 42;
say x x x;
The parser knows that say is a listop, and after that it expects a term. Thus the first x is term (here a variable), but since two terms in a row are forbidden, the next thing must be an infix operator (or maybe a semicolon to terminate the statement). Thus the second x is parsed as the repetition operator. And so on.
Predictive parsing is also what makes it possible to use the slash / both as an infix operator, and as a regex delimiter.
But even if it worked in theory, a sigil-less language with such a wealth of infix operators would probably be rather hard to read, and it would be much harder (if not impossible) to give good error messages in the case of syntax errors.
| [reply]
[d/l]
[select] |
Hm. If only that notion had been carried through to other operators...
Indeed. It works so well with most of the operators that it stands out so strongly when it doesn't work... such as the smartmatch operator.
| [reply] |
such as the smartmatch operator.
I've never used that in real code. Nor given/when for that matter.
I've tried to use both a few times for the sake of using them, and found that the reality didn't fit with my expectations, to the point where even reading the documentation over and over, I couldn't work out why I got the results I did. As such, neither have ever made it into my working vocabulary, despite that I know they are there.
Extending Perl requires far more than just implementing a few specific behaviours. It seems to me that you really need Mr Wall's particular brain -- and considerable time -- to see the full impact of such changes.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
I also haven't been able to "effectively use" the smart match operator. I've used it in some places to "just play around", but grep() or a List::Util function would have been just as good for the simple situations that I've used it in for experimentation.
I think that this thing is very complicated and is a "solution" in "search of a problem".
I haven't been able to figure out where this thing can be effectively used in ways that "normal" Perl is awkward or not sufficient. A big part of this is also whether or not the result of what it does is going to be "easily understandable".
| [reply] |
