不能计算出一个解析器的最小长度 - 在Haskell UU-parsinglib

Question

让我们来看看代码片段：

pSegmentBegin p i = pIndentExact i *> ((:) <$> p i <*> ((pEOL *> pSegment p i) <|> pure [])) 

，如果我在我的解析器更改此代码：

pSegmentBegin p i = do 
    pIndentExact i 
    ((:) <$> p i <*> ((pEOL *> pSegment p i) <|> pure [])) 

我有一个错误：

canot compute minmal length of a parser due to occurrence of a moadic bind, use addLength to override 

我认为上面的解析器应该表现相同的方式。为什么会出现这个错误？

编辑

上面的例子是非常简单的（为了简化问题）和它下面的说明是没有必要使用这里做记号，但我想它使用的实际情况如下：

pSegmentBegin p i = do 
    j <- pIndentAtLast i 
    (:) <$> p j <*> ((pEOL *> pSegments p j) <|> pure []) 

我已经注意到了，做的声明之前加入“addLength 1”解决了这个问题，但我不能确定它是否正确的解决方案：

pSegmentBegin p i = addLength 2 $ do 
    j <- pIndentAtLast i 
    (:) <$> p j <*> ((pEOL *> pSegments p j) <|> pure []) 

Answer 1

正如我已经提到的许多时候应尽可能避免monadic接口。让我试着解释为什么应用接口是首选。

我的图书馆的一个显着特点是它通过插入或删除问题来执行纠错。当然，我们可以在这里采取一个超前的预见，但这会使这个过程非常昂贵。所以我们只采取三步有限展望。

现在假设我们要插入一个表达和表达的备选方案之一是：

EXPR：=“如果” expr的“然后” expr的“其他” EXPR

那么我们要排除这种替代因为选择这种替代方案需要插入另一个表达式等等。因此，我们对替代方案进行抽象解释，并确保在抽签的情况下（即有限预测的等价成本），我们采用非递归替代方案之一。

不幸的是，当一个人写一元语法分析器时，这个方案崩溃了，因为绑定右边的长度可能取决于左边的结果。因此，我们发出错误消息，并要求程序员提供一些帮助，以指示此替代方案可能消耗的令牌数量。实际值并不重要，只要你没有为递归的东西提供有限的长度并且可能导致无限的插入。它仅用于在插入的情况下选择最短的替代方案。

这个抽象的解释有一定的成本，如果你写在单子风格你所有的解析器是不可避免的，这种分析被重复过的一遍又一遍。所以：如果使用这个库，如果有一个适用的替代方法，请不要使用单色风格的PARSERS。

Answer 2

它试图静态分析需要读取多少输入以优化性能，但这种优化需要一个静态已知的解析器结构 - 可以由Applicative构建的类型，因为解析器效果不能依赖于解析器值如(>>=)所做的。

所以这就是错误的 - 当您使用do表示法时，它会转换为Monadic绑定，从而打破Applicative预测器。如果库只暴露了两个接口中的一个接口，这样就不会发生这种错误，但如果在同一个解析器中同时使用这两个接口，则会有一些不一致。

由于这种使用do是严格不必要的 - 您不会使用monadic界面提供给您的额外功率 - 最好避免使用它。

Answer 3

我有一种变通方法我在uuparsinglib单子解析器使用。它是一种自我的答案在这里： Monadic parse with uu-parsinglib

您可能会发现它很有用