On Fri, Oct 14, 2005 at 08:38:55AM +0200, Peter Makholm wrote: : Yesterday I spend some hours getting pugs to understand : translitterations with multiple ranges in each pair. E.g. : : "foobar".trans( "a-z" => "n-za-n" ); : : By accident I tested something like: : : "foobar".trans( ['a' .. 'z'] => "n-za-m" ); : : and it didn't work. : : The problem is that ['a' .. 'z'] gets stringified to 'a b c d ...' : which gets 'b' translated to the third letter in the right hand side.
Hmm, why is stringification getting involved at all? We're intending transliteration to work with multi-codepoint sequences of various sorts, so the canonical representation of the data structure can't be simple strings. 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. One other quibble is that we're switching ranges in character classes to use ".." instead of "-", so trans should use the same convention. : Is this supposed to work and if so how should the code differ between : : "foobar".trans( ['a' .. 'b'] => '12'); # a=>1, b=>2 : "foobar".trans( "a b" => "123" ) # a=>1, ' '=>2, b=>3 Actually, the [...] is somewhat gratuitous. Should work with parens too. In fact, it should work with a bare range object on the left: "foobar".trans( 'a' .. 'b' => '12'); # a=>1, b=>2 : Same problem ocurs if left hand side is a string and right hand side : is an array reference but in this case the code implementing trans can : see it. Overzealous => stringification, I think. .trans can use a string as a list by splitting it, but the underlying structures must be lists. Thanks for working on this! Do you know any more people like you? :-) Larry
