Are / / strings uniformly interpreted in the language?

Quote-Like-Operators shows 2 interesting examples with tr:

    tr[aeiouy][yuoiea] or tr(+\-*/)/ABCD/.

// 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-Operators

Strings 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:

tr[aeiouy][yuoiea] or tr(+\-*/)/ABCD/.
[download]

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.

The last sentence should be (mangled tags): 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.

• Detecting 'our $foo => 1' mistake, not caught by warnings, except that it is
• Its better not to do detection, but simply force numification if you're expecting a number, and let warnings issue a warning
• Re^15: why are hex values not numbers? (octal)
• Re^5: "Useless use of a constant" in grep block? Are you sure that you, even if you're already a veteran, will never make this mistake?
• How often would you make this error? How often would you not notice that @ary didn't get filtered? Average programmer? rarely * rarely * rarely = warning unimportant
• perlcritic is where this type of extra help belongs , warnings is all full up
• Re: determine the variable causing the error: Use of uninitialized value (don't pretend no warnings)
• if you asked a brain surgeon to limit himself to those procedures that could be performed by an intern, or the eye surgeon to only use stitches that could be removed/replicated by a staff nurse, then medicine would be in a pretty poor state.
• Every legal document has to be clear and obvious so that any newly qualified lawyer that just barely scraped through law school can immediately apply it to every possible situation to which it might be applicable.
• Every annotation of the Human Genome should be so clear and obvious that any kid with a Junior Chemistry kit can whip themselves up a little brother or sister once they've finished their homework.
• Why does reverse in list context operate on () instead of @_ or @ARGV ? if we only had a time machine
• Re: perldoc of s///ee wrong or just misleading? (read more)

• Regexp::English ->new
      ->beginning_of_string
      ->literal('SR') ...
      

• (user supplied regex substitution without eval)
• other regex tools
• ppixregexplain.pl
• perl is fundamentally what it is, and it works the way it has for over a decade, if you don't like it, don't use it; calling it line-noise and cryptic at every turn is uninspired and uninteresting

I am talking about adding a simple warning, if symbols "[" and "$" in tr set1 or set2 are not backlashed (backslashing them is allowed in current version of Perl; also there is no break of compatibility with the old code here).

That's around a dozen of lines of code in C-language.

IMHO adding such a warning makes sense and this is a constructive suggestion, not blank critique of the language, as you assume. Your mileage may vary.