I have no objection to pattern operators like ::: in principle, but I do have a potential concern about them.
Given that the operators are actually defined in terms of "backtracking" within the RE engine, does this constrain the implementation such that it MUST be a backtracking implementation to behave correctly? If these operators are purely effeciency optimization hints, that would be one thing, but I get the sense that ignoring the "hints" might lead to incorrect behavior. (The <cut> operator might be a special concern.) Suppose, for the sake of argument, that someone wanted to make a pattern engine implementation, compatible with Perl 6 patterns, which was highly optimized for speed at the expense of memory, by RE->NFA->DFA construction for simultaneous evaluation of multiple alternatives without backtracking. This might be extremely expensive in memory, but there may be some niche applications where run-time speed is paramount, and a pattern is used so heavily in such a critical way that the user might be willing to expend hundreds of megabytes of RAM to make the patterns execute several times faster than normal. (Obviously, such a tradeoff would be unacceptable in the general case!) Would it be _possible_ to create a non-backtracking implementation of a Perl 6 pattern engine, or does the existence of backtracking-related operators preclude this possibility in advance? I hope we're not constraining the implementation options by the language design, but I'm worried that this might be the case with these operators. Shouldn't it be an implementation decision whether to use backtracking? Deven
