Re: RFC 165 (v1) Allow Varibles in tr///

[Stephen P. Potter]

Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis
pered:
| > > The way tr/// works is that a 256-byte table is constructed at compile
| > > time that say for each input character what output character is
| > 
| > Speaking of which, what's going to happen when there are more than 256
| > values to map?
| 
| It's already happened, but I forget the details.

Let me see if I understand this correctly.  For every tr/// in a program,
256 bytes have to be allocated?  Even if I only do something like tr/a/A/?
And, it is going to get worse for UTF8/UTF16?  Is this really the optimal
solution for this (sorry, this is probably going into -internals space).
Seems to me that we could very quickly end up with a really large memory
image.

-spp