While this issue should be solved at some point, it should not hold up the new translation scheme. It is unclear how to realize this feature in the compiler, especially when considering assignments to variables in closures. Consider for example,
oncetd(?Foo(x, Bar(y)))
A particular match of the pattern to some subterm may only fail at the match for the subpattern Bar(y), at which point x has already been assigned a value. The choice within oncetd has no knowledge of this variable.
Implementation would require some kind of stack to register assigned variables for each choice point.
Eelco Visser [2005-08-21 19:35]
While this issue should be solved at some point, it should not hold up the new translation scheme. It is unclear how to realize this feature in the compiler, especially when considering assignments to variables in closures. Consider for example,
oncetd(?Foo(x, Bar(y)))
A particular match of the pattern to some subterm may only fail at the match for the subpattern Bar(y), at which point x has already been assigned a value. The choice within oncetd has no knowledge of this variable.
Implementation would require some kind of stack to register assigned variables for each choice point.
(Is this treated correctly in the interpreter?)
Bug
Open
Critical
Unbind variables on backtracking
oncetd(?Foo(x, Bar(y)))
A particular match of the pattern to some subterm may only fail at the match for the subpattern Bar(y), at which point x has already been assigned a value. The choice within oncetd has no knowledge of this variable.
Implementation would require some kind of stack to register assigned variables for each choice point.
(Is this treated correctly in the interpreter?)