On Wed, 2004-09-01 at 16:07, Larry Wall wrote: > I see one other potential gotcha with respect to backtracking and > closures. In P6, a closure can declare a hypothetical variable > that is restored only if the closure exits "unsuccessfully". Within > a rule, an embedded closure is unsuccessful if it is backtracked over. > But that implies that you can't know whether you have a successful > return until the entire regex is matched, all the way down, and all the > way back out the top, or at least out far enough that you know you > can't backtrack into this closure. Abstractly, the closure doesn't > return until the entire rest of the match is decided. Internally, > of course, the closure probably returns as soon as you run into the > end of it.
Let's get concrete: rule foo { a $x:=(b*) c } "abbabc" So, if I understand Parrot and Perl 6 correctly (heh, fat chance), a slight modification to the calling convention of the closure that represents a rule (possibly even a raw .Closure) could add a pad that the callee is expected to fill in with any hypotheticals defined during execution. The following would happen in the example above: store_lex "bb" into hypopad("$x") after "abb" find "a" and fail the rule, backtracking (clear hypopad("$x")) store_lex "b" into hypopad("$x") after backtracking over one "b" find "b" next and fail the rule, backtracking again (clear) store_lex "b" into hypopad("$x") after second "ab" find "c" and succeed rule foo, return hypopad Essentially every close-paren triggers binding, and every back-track over a close-paren triggers clearing. Because this is all part of the calling convention for a rule, there's no difference between a rule "passing" back hypotheticals to its caller and a sub-rule doing so to the rule which called IT. Is that workable? Does it address your concern, Larry, or did I miss your point? -- â 781-324-3772 â [EMAIL PROTECTED] â http://www.ajs.com/~ajs