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

时间:2016-03-23 16:50:26

标签: regex perl

一些正则表达式引擎(好吧,就目前而言,只有Perl,据我所知)支持与回溯相关的动词:(*PRUNE)(*SKIP)(?{doSomeCode();}) *等。已经从here了解这些动词做什么

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

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

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

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

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

背景

根据the Perl regex tutorial,这些功能是实验性的(将来可能会删除)。难怪我无法在互联网上找到很多关于这些结构的内容(特别是当搜索被代码外部skipprune的无关结果堵塞时。我敢打赌,有很多人在正则表​​达式方面已经足够先进,使用这些动词根本就不了解它们。

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

  1. 功能是实验性的

  2. 功能不明显

  3. 功能先进

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

    我也知道closed (too opinion-based) question存在,但我不认为这个问题太基于意见了。我认为另一个问题是基于意见的,因为它要求" ",这意味着答案必须因人而异(我可以写出答案说“不,我没有错误,但没有错,但它也不会有帮助”。我会说唯一的答案是说"是"这个问题给出了两个链接,其中一个是深奥的用法(另外,我无法理解......)。另一个,虽然它给出了何时使用(*FAIL)的情况,但没有解决我提到的任何其他结构,也没有使用(*FAIL)作为回溯机制。据我了解,(*FAIL)可以模仿interface

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

    • 专门针对回溯
    • Non-Esoteric
    • 实践
    • 不仅仅是一个使用示例
    • 对任何给出的例子有解释
    • 可能包含添加功能的原因背景
    • 可能包含与功能未来相关的更新(包括Perl或其他正则表达式)

2 个答案:

答案 0 :(得分:2)

您可以看到的一个很好的文档是section about directives in Parse::RecDescent。特别是<commit>指令似乎与(*PRUNE)有某种关系(尽管也有(*COMMIT)),并且包含一个有启发性的例子。

我个人的印象是,他们大多数时候都会为您提供工具,使您的正则表达式更好(例如表现更好或更清晰),但不一定更有效。举个例子,你可能没有(*PRUNE),但是你会遇到更重的回溯以及这对你的影响取决于你想要匹配的东西。 Re (*FAIL),可能会使用不匹配的子正则表达式进行模拟,但它更清楚的意图是它至少增强了可读性。

答案 1 :(得分:0)

简而言之:您将知道是否需要使用它们,如果您不确定,请不要。

正如其他人所提到的,这些往往是适合语法处理的基于表现的优化工具。不仅是过早优化是所有邪恶的根源,这些特征直到最近才被标记为实验。因此,可以合理地推断出它们对于大多数用例来说并不是必需的,并且除非必要,否则最好不要去借助麻烦/复杂性。