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