什么时候应该使用正则表达式回溯控件,如(*PRUNE)?

Lau*_*rel 10 regex perl

一些正则表达式引擎(当然,只是Perl作为现在,据我所知)支持回溯相关的动词:(*PRUNE),(*SKIP),(?{doSomeCode();})*等我已经知道这些动词做的,从这里.

我对Perl只有一个非常基本的理解(所以尽可能避免依赖复杂的Perl代码),但我知道它是开创新正则表达式功能的语言.

根据我的理解,Perl似乎与正则表达式相比,与其他语言相比更加集成.出于这个原因,它的命令式风格已经渗透到其正则表达式中可能是有道理的.在其他具有正则表达式的语言中,即使优先考虑贪婪评估,正则表达式的基础样式也是声明性的(类似于SQL).

我倾向于认为这些动词有些深奥,或者至少是更低级别编程类型的不必要步骤.而不是需要(*PRUNE),不是更好(降低正则表达式编写器/程序员和读者的复杂性)在幕后进行更多优化(比如在编译器或引擎中)?

那么,在实际中,在正则表达式中包含与回溯相关的动词在什么情况下是有用的?这样做会有好处吗?


* 虽然在技术上不是回溯控制动词,但许多在正则表达式中执行任意代码的示例都会以影响或受回溯影响的方式执行.


背景

根据Perl正则表达式教程,这些功能是实验性的(将来可能会被删除).难怪我无法在互联网上找到很多关于这些结构的内容(特别是当搜索被代码中包含skip或不prune在外的无关结果堵塞时).我敢打赌,在正则表达式中有很多人已经足够先进,使用这些动词根本就不知道它们.

因此,目前存在许多妨碍广泛使用的实际障碍:

  1. 功能是实验性的

  2. 功能晦涩难懂

  3. 功能先进

以上3点是显而易见的,所以我想给出更多答案it's never useful because: 1, 2, or 3.如果可能的话,尝试给出一些背景,说明作者对这些动词的意图,和/或证明它们确实会被废弃(或者计划为他们设计另一个未来).

我也知道存在一个封闭的(过于基于意见的)问题,但我认为这个问题不太基于意见.我相信其他问题是,根据意见,因为它问:"有 ",这意味着答案必须因人而异(我也许能写的答案,说:"人无我有没有"没有它自己的错误,但它也不会有帮助).我会说,对这个问题说"是"的唯一答案给出了两个链接,其中一个是深奥的用法(另外,我无法理解......).另一个,虽然它给出了何时使用的情况,(*FAIL)但没有解决我提到的任何其他结构,也没有(*FAIL)用作回溯机制.根据我的理解,(*FAIL)可以通过任何总是失败的正则表达式来模拟.

让我在答案中重新说明我要找的内容:

  • 特别关注回溯
  • 非密宗
  • 实际的
  • 不仅仅是一个用法的例子
  • 对给出的任何例子都有解释
  • 可能包含添加功能的原因背景
  • 可能包含与功能未来相关的更新(包括Perl或其他正则表达式)

pol*_*tix 2

您可以查看的一篇很好的文档是关于 Parse::RecDescent 中的指令的部分<commit>特别是,该指令似乎在某种程度上与(*PRUNE)(尽管也有(*COMMIT))相关,并且包含一个有启发性的示例。

我个人的印象是,大多数时候他们为您提供工具来使您的正则表达式变得更好(例如性能更高或更清晰),但不一定更有效。举个例子,如果没有 ,您可能可以生活(*PRUNE),但是您会遭受更严重的回溯,这对您的影响取决于您想要匹配的内容。回复(*FAIL),它可能会用不匹配的子正则表达式来模拟,但更清楚的目的是它至少增强了可读性。