// is an abbreviation for m// (be careful of context). But // is can be replaced by (almost?) any delimiter, by using m or s or tr.
You make a very good point. Now I started to understand why they put description of tr, which is actually a function into this strange place
http://perldoc.perl.org/perlop.html#Quote-Like-OperatorsStrings with arbitrary delimiters after tr, m, s, etc are a special, additional type of literals. Each with its own rules. And those rules are different from rules that exist for single quoted strings, or double quoted strings or regex (three most popular types of literals in Perl).
For example, the treatment of backslash in "tr literal" is different from single quoted strings:
"A single-quoted, literal string. A backslash represents a backslash unless followed by the delimiter or another backslash, in which case the delimiter or backslash is interpolated."
This means that in Perl there is a dozen or so of different types of literals, each with its own idiosyncratic rules. Which create confusion even for long time Perl users as they tend to forget detail of constructs they use rarely and extrapolate them from more often used constructs.
For example, in my case, I was burned by the fact that "m literals" allows interpolation of variables, but "tr literals" do not. And even created a test case to study this behavior :-)
In other words, the nature of those "context-dependent-literals" (on the level of lexical scanner they are all literals) is completely defined not by delimiters they are using (which are arbitrary), but by the operator used before it. If there is none, m is assumed.
This "design decision" (in retrospect this is a design decision, although in reality it was "absence of design decition" situation ;-) adds unnecessary complexity to the language and several new (and completely unnecessary) types of bugs.
This "design decision" is also poorly documented and for typical "possible blunders" (for tr that would be usage of "[","$","@" without preceding backslash) there is no warnings.
This trick of putting tr description into http://perldoc.perl.org/perlop.html that I mentioned before now can be viewed as an attempt to hide this additional complexity. It might be beneficial to revise the docs along the lines I proposed.
In reality in Perl qq, qr, m, s, tr are functions each of which accepts (and interpret) a specific, unique type of "context-dependent-literal" as the argument. q can be interpreted (final string representation obtained) at compile time, so if this is not a function. That's the reality of this, pretty unique, situation with the language, as I see it.
Quote-Like-Operators shows 2 interesting examples with tr:The second variant look like a perversion for me. I never thought that this is possible. I thought that the "arbitrary delimiter" is "catched" after the operator and after that they should be uniform within the operator ;-).tr[aeiouy][yuoiea] or tr(+\-*/)/ABCD/.
And the first is not without problems either: if you "extrapolate" your skills with regex into tr you can write instead of
tr[aeiouy][yuoiea]
obviously incorrect
tr/[aeiouy]/[yuoiea]/
that will work fine as long as strings are of equal length.
In reply to Re^4: Strange behaviour of tr function in case the set1 is supplied by a variable
by likbez
in thread Strange behaviour of tr function in case the set1 is supplied by a variable
by likbez
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |