On Sat, Oct 15, 2005 at 01:27:58AM +0200, Juerd wrote: : Larry Wall skribis 2005-10-14 10:43 (-0700): : > Actually, it looks like the bug is probably that => is forcing : > stringification on its left argument too agressively. It should only : > do that for an identifier. : : Would it work to call this process autoquoting, instead of : stringification?
Yes, autoquoting is what => is supposed to do to its left argument, if it's an identifier. : I'm assuming other means of stringification do not : involve interpreting barewords. Depends on whether you count the stringification done by a slurpy hash on its keys as "other means of stringification". That seems to be what's going on here, even though the left side of => isn't an identifier. : > One other quibble is that we're switching ranges in character classes to : > use ".." instead of "-", so trans should use the same convention. : : Wasn't there going te be a feature to trans entire strings? i.e. 'foo' : => 'bar', where foo is a single thing replaced by bar. Does this not : exclude any possibility of specifying ranges in strings? Doesn't seem like a big problem. Presumably if you ever really want to translate to or from "..", you can make it an endpoint of its own pair in the pair list. On the other hand, I could see ".." happening accidentally in a string occasionally. And one can presumably construct ranges with a real ".." operator. So maybe the non-quote form of tr/// should always use lists, with a helper function to translate "a..z" to a list and also carp about the fact that it will break under Unicode. :-) Or maybe the argument is always a list of pair of (list or string), in which case we know the string at that level can be interpreted for "..", but a string within a sublist can't. If someone wants to work over the interface for consistency and flexibility, that'd be fine. Larry
