将 MonadError 与 Parsec 结合使用

Question

我正在尝试将 MonadError 与 Parsec 一起使用。我想出了以下代码片段：

f5 = do
    char 'a'
    throwError "SomeError"

f6 = f5 `catchError` (\e -> unexpected $ "Got the error: " ++ e)

ret = runErrorT (runParserT f6 () "stdin" "a")

但是，ret是Left“SomeError”，看来catchError没有任何效果。这里使用 MonadError 的正确方法是什么？

我更喜欢使用 MonadError 而不是 Parsec 自己的错误处理，例如当我有：

try (many1 parser1) <|> parser2

如果 parser1 在这里失败，parser2 将继续，但我希望有一个异常完全中止解析。

Answer 1

我的印象是您试图以错误的原因涉及 MonadError 。

在 try (many1 parser1) <|> 中parser2，您试图避免的行为源于 try 和 <|> 的使用 - 如果您不喜欢它，使用不同的组合器。也许像 (many1 parser1) >> 这样的表达式parser2 会更适合你吗？ （这会丢弃 (many1 parser1) 的结果；您当然可以使用 >>= 并组合 (many1 parser1) 的结果> 与来自 parser2 的内容。）

---

（注意：在这一点之下，目前的问题没有真正好的解决方案，只是一些关于为什么有些事情可能不起作用的思考。 .. 希望这可能（在某种程度上）具有启发性，但不要期望太多。）

对 ParsecT / MonadError 交互的仔细检查。恐怕有点混乱，我仍然不确定如何最好地去做OP想做的事情，但我希望以下内容至少能够深入了解缺乏成功的原因原来的方法。

首先，请注意说 Parsec 是 MonadError 的实例是不正确的。 Parsec 是当内部 monad 为 Identity 时由 ParsecT 产生的 monad；当且仅当给定一个内部 monad（它本身就是一个要使用的 MonadError 实例）时，ParsecT 才会生成 MonadError 的实例。 GHCi 交互的相关片段：

> :i Parsec
type Parsec s u = ParsecT s u Identity
    -- Defined in Text.Parsec.Prim
-- no MonadError instance

instance (MonadError e m) => MonadError e (ParsecT s u m)
  -- Defined in Text.Parsec.Prim
-- this explains why the above is the case
-- (a ParsecT-created monad will only become an instance of MonadError through
-- this instance, unless of course the user provides a custom declaration)

接下来，让我们来一个使用 catchError 和 ParsecT 的工作示例。考虑这个 GHCi 交互：

> (runParserT (char 'a' >> throwError "some error") () "asdf" "a" :: Either String (Either ParseError Char)) `catchError` (\e -> Right . Right $ 'z')
Right (Right 'z')

类型注释似乎是必要的（这对我来说似乎很直观，但它与原始问题无关，所以我不会尝试详细说明）。整个表达式的类型由 GHC 确定如下：

Either String (Either ParseError Char)

因此，我们得到了一个常规解析结果 - Either ParseError Char - 包装在 Either String 中> monad 代替通常的 Identity monad。由于 Either String 是 MonadError 的实例，我们可以使用 throwError / catchError，但处理程序传递给 < code>catchError 当然必须产生正确类型的值。恐怕这对于打破解析例程来说并不是很有用。

回到问题中的示例代码。这做了稍微不同的事情。让我们检查一下问题中定义的 ret 类型：（

forall (m :: * -> *) a.
(Monad m) =>
m (Either [Char] (Either ParseError a))

根据 GHCi...请注意，我必须使用 {-# LANGUAGE NoMonomorphismRestriction #-} 解除单态限制 让代码在没有类型注释的情况下进行编译。）

该类型暗示了使用 ret 做一些有趣的事情的可能性。我们开始吧：

> runParserT ret () "asdf" "a"
Right (Left "some error")

事后看来，给 catchError 的处理程序使用 unexpected 生成一个值，所以当然它将成为（可用作）解析器......而我恐怕我不知道如何将其锤炼成对打破解析过程有用的东西。

Answer 2

如果您尝试调试解析器来排除故障，那么使用 error、Debug.Trace 等可能会更简单。

另一方面，如果您需要终止对某些输入的解析作为实际程序的一部分，但由于 try (...) <|> 构造而没有这样做，那么你的逻辑中有一个错误，你应该停下来重新思考你的语法，而不是通过错误处理来解决它。

如果您希望解析器有时在给定的输入上终止，而不是其他时间，那么要么您的输入流中缺少某些内容（应该添加），要么解析器不能解决您的问题。

如果您希望解析器从非致命错误中优雅地恢复并在可能的情况下继续尝试，但在无法继续时以错误终止，那么您...可能需要考虑 Parsec 以外的其他东西，因为它确实没有设计为此。我相信乌得勒支大学的 Haskell 解析器组合器库更容易支持这种逻辑。

编辑：就 Parsec 本身是 MonadError 的一个实例而言，是的，它自己的错误处理包含了该功能。您要做的就是在秒差距之上堆叠一个第二错误单子，并且您可能会遇到麻烦，因为通常很难区分以这种方式“冗余”的单子转换器。处理多个状态单子是众所周知的尴尬，这就是为什么 Parsec（也是一个状态单子）提供保存自定义状态的功能。

换句话说，Parsec 作为一个错误单子对你没有任何帮助，事实上，它的相关性主要在于使你的问题变得更加困难。

Answer 3

如果您需要终止对某些输入的解析作为实际程序的一部分，但由于 try (...) <|> 而没有这样做构造，那么你的逻辑中有一个错误，你应该停止并重新思考你的语法，而不是通过错误处理来解决它。

如果你希望解析器有时在给定的输入上终止，而不是其他，那么要么您的输入流中缺少某些内容（应该添加），要么解析器不能解决您的问题。

这个答案基于问题在于语法的假设。但是，如果我使用语法来提供编译器，则会出现语法无法处理的其他错误。假设一个变量引用，指向一个未定义的变量。并且语言被指定为单次传递，并且变量在遇到时进行评估。然后，语法就没问题了。解析就好了。但是，由于评估语法中指定的内容，发生了错误，现有的“失败”或“意外”或不足以处理此问题。如果有一种方法可以中止解析而不诉诸更高级别的错误处理，那就太好了。