【发布时间】:2021-04-22 09:08:54
【问题描述】:
我目前正在试验类型类和作为练习,登录各种上下文的能力(即在 IO 的上下文中打印到控制台)。我首先将我的 Logger 实现为一个类型类,它由各种用于记录的函数组成,我的想法是我可以为 IO monad 定义一个实例,但在其他上下文中为其他实现留出空间单子。
最终结果是:
-- |Class / wrapper for convenient use within another monad.
class Logger m where
-- |Logs an error message /(prefixed with the '__[ERROR]__' tag)/
logError :: String -> m ()
-- |Logs a warning message /(prefixed with the '__[WARNING]__' tag)/
logWarning :: String -> m ()
-- |Logs a success message /(prefixed with the '__[SUCCESS]__' tag)/
logSuccess :: String -> m ()
-- |Logs an informative message /(prefixed with the '__[INFO]__' tag)/
logInfo :: String -> m ()
-- |Logs a regular message /(i.e with no prefix)/
logMsg :: String -> m ()
-- |Instance of logger in the IO monad
instance Logger IO where
logError = printError
logWarning = printWarning
logSuccess = printSuccess
logInfo = printInfo
logMsg = printMsg
-- |Instance of logger for a state
instance (MonadIO m) => Logger (StateT s m) where
logError = liftIO . printError
logWarning = liftIO . printWarning
logSuccess = liftIO . printSuccess
logInfo = liftIO . printInfo
logMsg = liftIO . printMsg
这在当时似乎是个好主意(并且来自 OOP 背景,我很喜欢把所有东西都变成“类”,而我可能不应该这样做)
我开始意识到我可以直接使用类型约束轻松定义我的日志记录函数,然后收工,例如:
logError :: (MonadIO m) => String -> m ()
logError = liftIO . printError
对于其他函数等等,我会有一些可以在任何基于 IO 的 monad 中调用的东西......
显然,这两种解决方案各有所长。
我的 Logger 类型类的用例是否可以被视为 “滥用” 或者我是否有正确的想法以这种方式实现它(我的理解类型类是否允许我想到的即席多态性)。
我读过的关于 & 的一个限制是我仍在尝试完全概念化的事实是,对于任何给定类型只能有一个类型类的实例,所以在我的例子中,我已经为 定义了一个实例StateT 存在于 IO 单子中,这意味着我失去了覆盖具有相同签名的后续状态的能力。我知道这一警告,但我很难想到这会成为一个具体问题的情况。
另一方面,简单的基于函数的方法使用起来同样优雅,尽管它确实可以防止在不定义要在不同上下文中使用的全新函数的情况下覆盖行为。
是否应该只在函数可以轻松完成工作时才使用/编写类型类?
我希望能对这两种方法提供一些见解和反馈。
提前致谢,
【问题讨论】:
-
每个帖子一个问题。
-
我已经更新了我的帖子,只包含一个问题,谢谢。
-
Haskell 很容易重构。所以先用简单的解决方案。
-
我认为您的
StateT实例应该有不同的约束:instance Logger m => Logger (StateT s m) where logError = lift . logError等 -
由于您来自面向对象的背景并询问有关日志记录的问题,您可能会发现我在Repeatable execution 上的系列文章很有用。这个由三部分组成的系列包括一个完整的 Haskell 示例,包括 GitHub 上的所有源代码。