Hello!
2013/3/10 duan yuxuan:
> 关于匹配中是否重置上下文，我觉得您可以提供一个开关，因为在实际中，很多时候会出现串包含的现象，
> 比如“.*ab”，“.*abc”，目前匹配了前面一个串就没法匹配后面的串了，有时一些特殊需求的情况下，sregex
> 就不能满足。（您是基于什么思想，在命中后要reset上下文？）
>
在流式匹配的上下文中，寻找 /re1|re2|re3/ 的可重叠的所有可能匹配的开销过大，所以多正则匹配的语义是类似
tokenizer，或者说词法分析器。一个这样的例子是 lex. 我们在匹配时总是只选出 left-most,
highest-priority 的正则（或者正则 alternative 分支），而优先级在这里是由先后次序决定的（在 lex
中则不同，是 longest-token match 语义）。这也符合 Perl 5 正则的 m/re/g 全局匹配操作的语义。
> 今天给你mail主要是另外一个问题：
> 我发现如：
> ./sregex-cli -n 2 ".*abc" ".*def" "123defabc"
>
> 结果会匹配第一个串，而第二个却匹配不了，我觉得应该是要匹配以一个才符合逻辑的，
在你这个例子中，这两个正则表达式的匹配起始位置都是
0（即输入字符串的开头），于是决定谁匹配的是二者的相对优先级，而第一个正则的优先级总是高于第二个正则，所以第一个正则先匹配，然后正则引擎会接着从前一个匹配（即
/.*abc/ 匹配的 123defabc
子串）的结束位置继续向下匹配这两个正则。显然，此时当前处理指针已到达输入串的末尾，找不到更多的匹配了。
> 我看了sre_vm_pike_exec，您的实现应该是：
>
> 对于输入的字符x,确定状态机中每个模式串的下一个状态。
>
> 但从匹配结果来看，好像是：
>
> for（patterns）
> {
> 对于给定的数据，这个串是否命中。
> }
>
这个解释也是错误的。可以考虑下面这个例子：
./sregex-cli -n 2 "abc" "def" "123defabc"
此时首先匹配的是第二个正则，因为第二个正则的匹配起始位置在第一个正则匹配起始位置的左边，即 left-most
胜出。只有当二者起始位置相同时，才会按优先级决出胜负。
对于 sregex 正则引擎的多用户正则模式，所有参与匹配的用户正则在语义（以及实现上）都是直接用 | 运算符按序拼接成一个大正则进行匹配的。
再次抄送给 openresty 中文邮件列表：https://groups.google.com/group/openresty 建议你加入
openresty 中文邮件列表并在那里讨论 sregex 相关的细节问题。谢谢合作。
Best regards,
-agentzh
