关于Haskell中‘Embed, don't Stack’的定义及实践的技术问询

1. “Embed”术语的通用定义 #

在Haskell生产开发语境下，Embed并没有标准化的通用学术定义，但它是针对Monad Transformer Stack（单子变换器栈）模式提出的替代思路：它指的是将应用所需的各类Effect（比如日志、数据库访问、配置读取等），作为独立的字段直接嵌入到自定义的应用环境类型（通常命名为App）中，而非通过层层嵌套的单子变换器来叠加这些Effect。

这种思路的核心是把Effect的实现实例“内嵌”到应用环境里，让业务逻辑通过读取环境来获取Effect能力，而非依赖变换器栈的层级来传递Effect上下文。

2. 该模式在实践中的具体形态 #

我们通过对比传统的变换器栈写法和嵌入式写法来理解：

传统Monad Transformer Stack写法 #

假设我们需要日志、数据库和配置三个Effect，传统写法会堆叠对应的变换器：

-- 定义栈类型
type AppStack m = ReaderT Config (LoggingT (DBT m))

-- 业务函数的类型签名会包含整个栈
fetchUser :: AppStack IO User
fetchUser = do
  config <- ask
  logInfo $ "Fetching user with config: " <> show config
  dbResult <- runDB $ queryUserById 1
  pure dbResult

这种写法的问题在于，栈的层数越多，类型签名越复杂，而且Effect之间的耦合度高，调整栈结构会牵扯大量代码。

嵌入式“Embed”模式写法 #

嵌入式模式会把所有Effect封装到App环境类型中：

-- 定义App环境，直接嵌入各类Effect的实现/句柄
data App = App
  { appConfig :: Config
  , appLogger :: Logger
  , appDB :: DBConnection
  }

-- 定义App monad，通常基于ReaderT（只需要一层，用来读取App环境）
newtype AppM a = AppM { runAppM :: ReaderT App IO a }
  deriving (Functor, Applicative, Monad, MonadIO, MonadReader App)

-- 为每个Effect提供独立的操作函数，从App环境中获取对应的句柄
logInfo :: String -> AppM ()
logInfo msg = do
  logger <- asks appLogger
  liftIO $ loggerInfo logger msg

queryDB :: DBQuery a -> AppM a
queryDB q = do
  conn <- asks appDB
  liftIO $ runDBQuery conn q

-- 业务函数的类型签名简洁，只依赖AppM
fetchUser :: AppM User
fetchUser = do
  config <- asks appConfig
  logInfo $ "Fetching user with config: " <> show config
  dbResult <- queryDB $ QueryUserById 1
  pure dbResult

嵌入式模式的核心特点 #

• Effect独立解耦：每个Effect的实现都封装在App环境的独立字段中，调整某个Effect的实现（比如换日志库），只需要修改对应字段和操作函数，不影响其他Effect。
• 类型签名简洁：业务函数统一使用AppM，不需要暴露复杂的变换器栈类型，可读性和维护性更强。
• 灵活的组合方式：可以在App环境中随意添加或移除Effect字段，不需要重新调整变换器栈的层级。
• 明确的依赖注入：通过ReaderT读取App环境，本质是依赖注入模式，让业务逻辑依赖抽象的Effect能力，而非具体的实现。

内容的提问来源于stack exchange，提问作者Dwayne Crooks