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