比代数数据类型更喜欢 CPS 的要求是什么？答案

【问题标题】：What are the requirements to prefer CPS over algebraic data types?比代数数据类型更喜欢 CPS 的要求是什么？
【发布时间】：2021-01-18 10:09:58
【问题描述】：

我对代数数据类型几乎没有经验，因为我使用的语言没有原生支持。通常可以使用延续传递风格来获得远程相似的体验，但 CPS 编码类型的处理不太舒服。

考虑到这一点，为什么像 Parsec 这样的库会使用 CPS？

newtype ParsecT s u m a
    = ParsecT {unParser :: forall b .
                 State s u
              -> (a -> State s u -> ParseError -> m b) -- consumed ok
              -> (ParseError -> m b)                   -- consumed err
              -> (a -> State s u -> ParseError -> m b) -- empty ok
              -> (ParseError -> m b)                   -- empty err
              -> m b
             }

一个线索是 try 解析器，它通过在两种情况下传递 empty error 延续来排除 consumed error 情况：

try :: ParsecT s u m a -> ParsecT s u m a
try p =
    ParsecT $ \s cok _ eok eerr ->
    unParser p s cok eerr eok eerr
--                   ^^^^     ^^^^

这是可能的，因为两个延续 cerr 和 eerr 具有相同的类型，只是它们的位置不同，这让我想起了结构类型。虽然我认为你不能用 ADT 做到这一点，但可能有一种方法可以用它们实现相同的行为。除此之外，单个组合器无法证明依赖 CPS 的影响深远的决定是合理的。那么为什么会做出这个决定呢？

【问题讨论】：

我认为这里有性能优势 - 减少中间结构。就表现力而言，我认为它们是“平等的”。
我相信这是一个古老的设计决定，最初是出于性能原因，但在现代 GHC 上，非 CPS 解析器比 CPS 解析器快得多。对于可恢复解析器，尽管 CPS 提供了一个简单的实现。
@AndrásKovács 你有一些方便的链接来比较两者的基准比较吗？我有兴趣阅读更多内容。
@AndrásKovács，我记得非常现代的 serialise 包使用 CPS，但采取了其他步骤来避免过度依赖优化器（也许避开专业化？）。再说一次，解析和反序列化不一样。
对于序列化，非 CPS persist 是几个非 CPS 最快的选择之一。对于解析，bytesmith 和未发布的 parsnip 和 flatparse 库是 AFAIK 最快的。他们都使用未装箱的总和，没有 CPS。他们比较边缘，但我对评估很有信心。

标签： haskell functional-programming algebraic-data-types continuation-passing

【解决方案1】：

此更改由 Antoine Latter 于 2009 年 3 月 2 日在 commit a98a3ccb 中进行。提交评论只是：

commit a98a3ccbca9835fe749b8cd2d475a0494a84a460
Author: Antoine Latter <aslatter@gmail.com>
Date:   Mon Mar 2 00:20:00 2009 +0000

    move core data type over to CPS

它取代了 ParsecT 的原始 ADT：

data ParsecT s u m a
    = ParsecT { runParsecT :: State s u -> m (Consumed (m (Reply s u a))) }

在您的问题中使用新版本，添加 runParsecT 适配器以将所有内容转换回来：

runParsecT :: Monad m => ParsecT s u m a -> State s u -> m (Consumed (m (Reply s u a)))
runParsecT p s = unParser p s cok cerr eok eerr
    where cok a s' err = return . Consumed . return $ Ok a s' err
          cerr err = return . Consumed . return $ Error err
          eok a s' err = return . Empty . return $ Ok a s' err
          eerr err = return . Empty . return $ Error err

我看到他写了一个blog post in February 2009，在那里他写了关于最终理解CPS 风格的文章，并写了关于MaybeT 的CPS 版本。他没有谈论任何性能优势，只是指出 CPS 样式的优势在于，MaybeT 的 MonadPlus 和 MonadPlus 实例可以在不调用底层 monad 或 >>= 或 return 的情况下编写对Maybe 值进行显式案例分析。

在后来的December 2009 blog post 中，他写到了他“对功能化 monad 转换器的痴迷”，给出了一个 ErrorT 的例子并明确指出：

我还没有对这是否比任何事情都更快进行基准测试，但我发现整个事情很有趣。

然而，他随后在同一篇博文中继续讨论如何向 Parsec 3 添加功能以使其成为 monad 转换器而不是普通的旧 monad，并在输入类型 led 上对其进行参数化性能不佳（在某些基准测试中大约慢 1.8 倍）。他发现，转换为 CPS 样式使 Parsec 3 的速度与 Parsec 2 一样快，至少在不使用那些新的抽象（转换器）时是如此。

关于时间的推测，我认为 Antoine 认为 CPS 很“酷”并且具有吸引他的风格优势，因此他在开发 Parsec 3 时将其放在首位。当 Parsec 3 中的新抽象带来性能时问题，他偶然发现将其转换为 CPS 似乎可以解决这些问题，尽管他没有详细研究原因（只是博客文章中的一些猜测）。但是，我有点不清楚他是实际上在发现性能优势之前先转换为 CPS，还是尝试 CPS 并期望它可能有助于提高性能。这篇博文读起来像是有意进行转换以解决性能问题，但这可能只是为了在博文中进行更简单的说明。

【讨论】：

【解决方案2】：

一个大问题是ParsecT 是一个 monad 转换器，使用 ADT 定义的 monad 转换器比使用 CPS 的 monad 转换器更能阻止优化。

表达式pure x >>= k :: ExceptT e m a 给出了一个最小的说明性示例。

将ExceptT e m a 定义为m (Either e a)，表达式并不能很好地简化，因为它涉及到抽象的底层单子m 的(>>=)。
将ExceptT e m a 定义为forall r. (Either e a -> m r) -> m r，pure x >>= k 基本上 beta-reduce 到 k x，而不对 m 做任何假设。

您需要专门化 m 以优化 m (Either e a) 类型的术语，而基于延续的变体在没有专门化的情况下可以走很长的路。

但是，CPS 也不是 Haskell 中的理想表示，因为延续是在堆上分配的函数。函数很便宜，但不是零成本。

归根结底，monad 转换器中 m 的抽象性确实会妨碍您进行优化，您必须专门化，即打破模块化。因此，一种更有前途的方法是使用一些特殊的原始 monad (IO)，并得到运行时系统的专门支持，作为效果系统的基础。

另见谈话Effects for Less, by Alexis King，以及相关库eff。

【讨论】：