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

>Lightning flashed, thunder crashed and Mark-Jason Dominus <[email protected]<SNIP>
>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?  

Yes, once upon a time.

>Even if I only do something like tr/a/A/?
>And, it is going to get worse for UTF8/UTF16?  

Use the Source.

>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.

Memory usage is irrelevant compared with speed.

--tom