这是Haskell主要功能的有效设计模式吗？

Question

在开发了几个Haskell应用程序之后，我发现自己严格地将不纯代码和可故障(部分)函数与它们的纯合计函数隔离开来。这些努力明显降低了与应用程序相关的维护成本。随着时间的推移，我发现自己依赖于同样高级别的main结构来实施这种隔离。

一般来说，我的

main将有以下结构：

import System.Environment

data ProgramParameters = P ()
data ComputationResult = I ()

main :: IO ()
main = getArgs                           -- Collect arguments
   >>= andOrGetUserInput                 -- Collect user input
   >>= impureOrFailableComputations      -- Possible non-recoverable error(s)
   >>= either                            -- "Branch"
         putStrLn                        -- Print Any Failure(s)
         pureNotFailableComputations     -- Finish the work

andOrGetUserInput :: [String] -> IO ProgramParameters
andOrGetUserInput = undefined

impureOrFailableComputations :: ProgramParameters -> IO (Either String ComputationResult)
impureOrFailableComputations = undefined -- a composition of partial functions
                                         -- made total by catching exceptions & input errors
                                         -- in the short-circuiting ErrorT/EitherT monad

pureNotFailableComputations :: ComputationResult -> IO ()
pureNotFailableComputations = undefined  -- a composition of total functions

其目标是将部分计算合并到一个单一计算中，从而创建一个整体的一元计算。

这已经成为代码库中的一种模式，我想要反馈这是设计模式还是反模式。

• 这是一种分离和捕获部分计算的惯用方法吗？
• 这种高度的隔离有明显的缺点吗？
• 有更好的抽象技术吗？

Answer 1

这个设计做出了几个重要的假设：

• 用户的输入将不依赖于纯粹或不纯计算的结果。
• 不纯的计算将不依赖于纯计算的结果。
• 程序逻辑不会循环；它只运行一次。

我对你的结构的另一个评论是，你不需要分开纯粹和不纯的计算。哈斯克尔的类型系统已经为你做到了。

尽管如此，这种结构对于某些类型的程序确实是有用的，尤其是如果您确信我上面描述的假设对于您的程序来说确实是正确的。不过，这不是每个程序都应该使用的东西。