On 2010-06-03, at 3:13 am, Moritz Lenz wrote: > ... unless you push all the replacement markers onto an array, and > traverse the array during the substitution phase.
I thought of that, but it didn't work when there's a case of longest-token matching. That is, if you try to match both 'A' and 'AB', Rakudo recognises the 'A' first, and executes its closure; then it finds the 'AB', and executes its closure too. Which works out with assignment, since the longest match ends up overwriting the previous tentative side-effect; but with pushing, you end up using both. Actually, that sounds like it's probably a bug? Presumably only the closure associated with the longest token should be executed, not the ones associated with partial tentative matches. In other words, this ought to say "ab" only, not both: "ABC" ~~ / A {say "a"} | AB {say "ab"} / (And playing around with it, it looks like Rakudo is handling | like ||: "ABC" ~~ /A|AB/ is returning "A", not the longest token "AB"....) > I don't like the code duplication in .subst and .match, I'd rather see > .trans working with the workarounds I mentioned above than re-writing > .subst to re-implement much of .match. Yup. I can't think of a good workaround for the closure issue, but rather than mangle .subst, I changed my trans to do the replacement itself for now. (Which is the better way to handle it anyway. It doesn't need to handle all the options that .subst does, so it's cleaner too.) I didn't find a way to create separate regexes without using eval(). Playing around with scope didn't help the way it would have in P5, but I'm thinking the proper way to do it would be with something like Regex.new()? >> (It passes the same spectests from subst.t that it did before, except for a >> couple that I'm not sure are right.) > I'll look through the tests and weed out the old, wrong tests. They were a couple of tests using :p and :g, but I was reading them wrong. (Or at least, now I see how they were intended, so the tests do make sense.) -David
trans.p6
Description: Binary data