On Tue, Jan 16, 2007 at 02:05:44PM -0600, Patrick R. Michaud wrote: : On Tue, Jan 16, 2007 at 10:41:03AM -0800, Larry Wall wrote: : > Note, in case you don't read synopsis checkins: the previous checkin : > majorly changes the semantics of | within regex to support required : > longest-token matching semantics rather than left-to-right matching. : > This is nearly on the same philosophical level as requiring the : > tail-recursion optimization. It will enable us to write parsers : > more consistently, and it also opens up normal regexes to better : > optimization via tries and such. You can now use || for the old | : > semantics, which is majorly consistent with how | and || work outside : > of regexen. : : Do we leave C<&> alone (as opposed to introducing a corresponding C<&&> : operator)? I can see arguments both ways.
Good question... I think let's go ahead and put in && as well to guarantee order. Then & can evaluate in any order it likes, including even interleaved if it doesn't want one branch to get too far ahead of the other, or if it can figure out that one branch can falsify earlier or more often than the other. Or it could make a dynamic decision which branch to try first based on past history. And it could compare prefix sets fore and aft to traverse with a single trie if it wants to factor out the common prefix, I guess. Though I suppose that could happen anyway. But mostly I think we just do it for consistency, and to avoid a FAQ. Larry
