【问题标题】:Typeclasses vs. functions?类型类与函数?
【发布时间】: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 上的所有源代码。

标签: haskell typeclass


【解决方案1】:

绝对重用已经做你关心的事情的类型类——在这种情况下,MonadIO

也就是说,我认为日志记录是一个特别有趣的应用程序。例如,考虑AccumT [String] IO。日志应该提升IO 操作还是add?不清楚一个明显正确,另一个明显不正确。出于这个原因,您甚至可以考虑从 typeclass 路由(每种类型只能有一个实现)转到 ADT 路由:

-- incidentally, you should use this in your class, too
data Level = Error | Warning | Success | Info | Msg
    deriving (Eq, Ord, Read, Show, Bounded, Enum)

newtype Logger m = Logger { log :: Level -> String -> m () }

那么你可以对AccumT 有单独的实现:

makeLoggingMessage :: Level -> String -> String
makeLoggingMessage lev msg = show lev ++ ": " ++ msg -- or whatever

viaIO :: MonadIO m => Logger m
viaIO = Logger $ \lev msg -> liftIO . putStrLn $ makeLoggingMessage lev msg

viaAccum :: Monad m => Logger (AccumT [String] m)
viaAccum = Logger $ \lev msg -> add [makeLoggingMessage lev msg]

可能还有其他变体;例如,一个添加时间戳,一个不添加时间戳。

顺便说一句,这个数据类型建议不仅仅是学术性的。 lumberjack 库的 LogAction 数据类型1 几乎就是这个,围绕它构建了一个完整的库,并且被专业的 Haskell 程序员使用。

在现有类型类、新类型类或数据类型这三个选项之间进行选择是您将慢慢获得经验的事情。根据经验,我能给新手关于这个主题的最可靠的建议可能是:不要创建新的类型类。 ^_^

1有些人可能还从co-log 库中认出了这一点,我听说这是伐木工人设计的重要灵感。

【讨论】:

  • 我没有像你建议的那样考虑使用 newtype 的可能性,这绝对是我想调查的一种途径。它看起来更冗长,因为你必须有不同命名的实现,但它看起来确实更强大和可扩展。除了您的回答和以前的 cmets,我觉得这很好地回答了这个问题,并提供了足够的途径使各个替代方案的好处变得清晰。
猜你喜欢
  • 1970-01-01
  • 2013-11-10
  • 1970-01-01
  • 1970-01-01
  • 2014-10-24
  • 2018-12-24
  • 2020-07-18
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多