Re: RFC 165: Allow variables in a tr///

Stephen Potter wrote:
>Personally, I would say that q/.../ and friends were a bad idea.  A lot of
>non-gurus see /.../ (whatever comes before it) and their first impression
>is that it has something to do with regex.  I would suggest that anything
>that isn't a regex should not use /.../.  Make q, qq, etc use matched
>pairs.  Make tr look like a regular function and do 
>tr(SEARCH, REPLACE, MOD, STR).  It just seems more orthagonal to me.


I respectfully disagree.

I don't know what you're meaning by "orthogonal" (note spelling) here,
but I *like* having MTOWTDI.

I *often* do s|foo|bar|, especially when "foo" or "bar" have slashes
in them. My programs often output code in other languages; having the
flexibility to use whatever quote character I like is a big win.

If a beginner sees /.../ and their first impression is that it should
be doing something regexish, and it doesn't, then the beginner has a
fine opportunity to *learn*. If the syntax were inherently confusing
and difficult to learn, that would be a different thing. But "Feature
X is confusing to beginners" is not, in and of itself, a good argument
for a language change.

"Beginners are confused by X" is a decent bolstering argument as to 
why X should be changed, but it's a lousy primary argument.
 ----------------------------------------------------------------------
 Eric J. Roode,  [email protected]           print  scalar  reverse  sort
 Senior Software Engineer                'tona ', 'reh', 'ekca', 'lre',
 Myxa Corporation                        '.r', 'h ', 'uj', 'p ', 'ts';