haskell - 自由 Monad 与显式传递函数

Question

我正在探索 Haskell 中的选项，这些选项可以让我将业务逻辑与底层系统的技术实现分开。例如，在 Web 服务器的上下文中，将 Web 服务器处理其接收的信息的方式与其读取和写入数据库的方式分开。要做到这一点，有很多选择，但有两个特别引起了我的注意:释放 Monad 和传递功能记录作为参数。我很难看出其中一种相对于另一种的优缺点。

用于说明我正在讨论的内容的代码片段:

module Lib where

import qualified Control.Monad.Free as FreeMonad

data MyGadt x
  = Read (String -> x)
  | Write String
          x

instance Functor MyGadt where
  fmap f (Read g)      = Read (f . g)
  fmap f (Write str x) = Write str (f x)

programWithFreeMonad :: FreeMonad.Free MyGadt ()
programWithFreeMonad = do
  msg <- FreeMonad.liftF $ Read id
  FreeMonad.liftF $ Write msg ()

ioInterpreter :: FreeMonad.Free MyGadt x -> IO x
ioInterpreter (FreeMonad.Pure x)             = return x
ioInterpreter (FreeMonad.Free (Read f))      = getLine >>= (ioInterpreter . f)
ioInterpreter (FreeMonad.Free (Write str x)) = putStrLn str >> ioInterpreter x

runProgramWithFreeMonad :: IO ()
runProgramWithFreeMonad = ioInterpreter programWithFreeMonad

data Capabilities m = Capabilities
  { myRead  :: m String
  , myWrite :: String -> m ()
  }

programWithCapabilities :: Monad m => Capabilities m -> m ()
programWithCapabilities capabilities = do
  msg <- myRead capabilities
  myWrite capabilities msg

runProgramWithCapabilities :: IO ()
runProgramWithCapabilities =
  programWithCapabilities $ Capabilities {myRead = getLine, myWrite = putStrLn}

这两种解决方案的编写方式不同，因此我认为许多人对其外观以及他们更喜欢哪一种都有自己的看法。但我想知道是否有人对一种解决方案相对于另一种解决方案的优缺点有任何见解。

Answer 1

即使我们限制自己在自由 monad 和函数记录之间进行选择(不考虑涉及 monad 转换器堆栈和类似 MTL 的类型类的解决方案)，仍有很多争论正在进行，而且问题还没有解决。

传统上，简单的 free monad 被指责有两个缺陷:运行时效率低下(这可能重要也可能不重要，这取决于解释器操作的速度相比而言有多慢)和缺乏可扩展性(如何将一个程序提升到另一个程序中)有更丰富的效果吗？)。

"Data types a la carte"首先尝试解决可扩展性问题。后来，"Freer Monads, More Extensible Effects"论文发表，提出了一种更复杂的自由类型来提高单子(monad)绑定(bind)的效率，同时也是定义操作集的可扩展方式。实现这种方法的主要库是:

• freer-simple这群人中最容易理解的，显然也是最慢的。好像对括号类型的操作有一些限制。

• fused-effects更高效的库，允许括号类型操作。但类型也比较复杂。

• polysemy相对较新的库，旨在快速并支持括号类型操作，同时保留简单类型。

这些库的一个吸引人的方面是它们可以让您零碎地解释效果，挑选出一种效果，同时不解释其余的效果。您还可以将抽象效果解释为其他抽象效果，而无需立即转到 IO。

<小时/>

至于功能记录方法。像 programWithCapability 这样的程序在基本 monad 上是多态的，并且记录由 monad 参数化的函数，在概念上与所谓的 van Laarhoven Free Monad 相关。 :

-- (ops m) is required to be isomorphic to (Π n. i_n -> m j_n)
newtype VLMonad ops a = VLMonad { runVLMonad :: forall m. Monad m => ops m -> m a }

instance Monad (VLMonad ops) where
  return a = VLMonad (\_ -> return a)
  m >>= f = VLMonad (\ops -> runVLMonad m ops >>= f' ops)
   where
    f' ops a = runVLMonad (f a) ops

来自链接的帖子:

Swierstra notes that by summing together functors representing primitive I/O actions and taking the free monad of that sum, we can produce values use multiple I/O feature sets. Values defined on a subset of features can be lifted into the free monad generated by the sum. The equivalent process can be performed with the van Laarhoven free monad by taking the product of records of the primitive operations. Values defined on a subset of features can be lifted by composing the van Laarhoven free monad with suitable projection functions that pick out the requisite primitive operations.

似乎不存在(？)为您提供预制 VLMonad 类型的库。确实存在的是记录函数但通过 IO 工作的库，例如 RIO 。人们仍然可以对逻辑中的基本 monad 进行抽象，然后在运行逻辑时使用 RIO。或者更喜欢简单性并撕开将 IO 隐藏在逻辑中的多态面纱。

函数记录方法可能具有更容易掌握的优点，是直接在 IO 上工作的增量升级。它也更类似于进行依赖注入(inject)的面向对象方式。

使用唱片本身的人体工程学变得至关重要。目前常用"classy lenses"使程序逻辑独立于具体的记录类型，方便程序的编写。也许有一天也可以使用可扩展记录(就像在更自由的方法中使用可扩展总和类型一样)。