Do you know where your variables are? | |
PerlMonks |
Re^4: Strange behaviour of tr function in case the set1 is supplied by a variableby likbez (Sexton) |
on Nov 16, 2017 at 20:05 UTC ( [id://1203618]=note: print w/replies, xml ) | Need Help?? |
// 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 ;-). 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 Section
Seekers of Perl Wisdom
|
|