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

> When does the structure get built?  That's why eg. tr[a-z][A-Z] 
> brooks no variables, for it is solely at compile time that these
> things occur, and why you must resort to delayed compilation via
> eval qq/.../ to prod the compiler into building you a new one.

Certainly.   But if there were no variable interpolation for regexes,
you could make the same argument about regexes.  I don't see any
reason why the regex solution couldn't or shouldn't be extended to
tr/// also.  If the pattern and replacement sets contain variables,
then table construction can be deferred until run time; if there are
no variables, the table is computed at compile time.

Building a tr/// table is much much simpler and much less work than
compiling a regex, but we don't make people write

        eval " \$s =~ m/$pat/ "

when they want to interpolate a string into a regex at run time.
Instead, we take care of it transparently.  tr/// could easily be made
to work the exact same way.

> Maybe you want qt/.../.../ or something.

I don't think a new notation is necessary in this case.  All that's
needed is a small extension to the existing semantics, in a direction
that has already been thoroughly investigated.