haskell - 类型类与函数?
问题描述
我目前正在试验类型类和作为练习,登录各种上下文的能力(即在 IO 的上下文中打印到控制台)。我首先将我的Logger实现为一个类型类,它由各种用于记录的函数组成,并考虑到我可以为 IO monad 定义一个实例,但在其他 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中monad,这意味着我失去了覆盖具有相同签名的后续状态的能力。我知道这个警告,但我很难想到这将成为一个具体问题的情况。
另一方面,简单的基于函数的方法使用起来同样优雅,尽管它确实可以防止在不定义要在不同上下文中使用的全新函数的情况下覆盖行为。
当函数可以轻松完成工作时,类型类是否应该仅作为最后的手段使用/编写?
我将不胜感激有关这两种方法的一些见解和反馈。
提前致谢,
解决方案
绝对重用已经做你关心的事情的类型类——在这种情况下,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]
也可能有其他变体;例如,可能一个添加时间戳,一个不添加时间戳。
顺便说一句,这种数据类型建议不仅仅是学术性的。伐木工人库的LogAction数据类型1几乎就是这样,围绕它构建了一个完整的库,并被专业的 Haskell 程序员使用。
在三个选项(现有类型类、新类型类或数据类型)之间进行选择是您将慢慢获得经验的事情。根据经验,我能给新手关于这个主题的最可靠的建议可能是:不要创建新的类型类。^_^
1有些人也可能从co-log库中认识到这一点,我听说这是伐木工人设计的重要灵感。
推荐阅读
- cmake - 如何使用可移植的 CMake 在 C99 项目中添加和使用资源?
- import - 从 Flutter 中的父目录导入
- c++ - 为什么我不能在主函数中更改一个类的公共变量
- docker - Docker swarm 服务端口未暴露
- c# - 为什么类中的存储过程数据不显示在我的表单的 Datagridview 中
- azure - Azure Kubernetes 的 NGiNX Ingress Controller 是否支持多种协议
- matlab - 在matlab中绘制三次根
- c# - .NET 核心实体框架 - 转义“@”字符
- android - 如何将页脚添加到 Gridview?
- c++ - 为什么这种获取 CPU 利用率的方法产生的结果比任务管理器中的方法低 2 倍?