在他的Monad Reader article on Hoogle p.33中，Neil Mitchell主张将Haskell项目捆绑成具有多种模式的单个可执行文件。 （仅供参考，Neil Mitchell的CmdArgs库使这很简单。）因此，可能有一种模式可以启动Web服务器，另一种模式可以从命令行查询数据库等。引用：
提供一个可执行文件
版本3有四个可执行程序 - 一个用于生成排名 信息，一个做命令行搜索，一个做web 搜索，一个做回归测试。版本4有一个 可执行文件，完成上述所有操作，由fl ags控制。 提供一个终端程序有很多好处 - 它 它可以减少代码破坏的几率而不会注意到它，它可以实现 不重复Haskell运行时系统，总文件大小更小， 它减少了用户需要学习的命令数量。搬到了 一个多功能可执行文件似乎是一个常见的主题，哪些工具 例如darcs和hpc都基于一个带有多个命令的命令 模式。
我的问题：通常认为Haskell中的最佳实践是将所有内容放在一个更大的单片可执行文件中，而不是遵循“Unix哲学”并构建通过数据库或通信进行通信的小型，独立，互操作的Haskell程序文字流？
我可以看到一个大型的单片Haskell程序如何通过在整个系统中共享核心数据类型来更好地利用类型安全性。但是针对大型巨石的标准警告似乎仍然适用，包括依赖性冲突的风险增加。
答案 0 :(得分：1)
经常有许多Unix工具通过子命令提供复杂的功能，我认为它们的数量最近一直在增长。
我的第一个例子是Unix shell。有几个内置命令，各种shell构建在不同的命令集中，而其他命令则实现为二进制文件。
另一个经典的Unix示例是vi编辑器。许多实现提供了只读文件查看器（视图）的功能以及基于命令的编辑器（ex），具体取决于调用二进制文件的名称。二进制文件以多个名称链接到文件系统，因此相同的二进制文件提供了所有工具。
作为一个更现代的例子，git版本控制包的实现方式与我描述的方式类似，尽管它有一小部分二进制文件链接为很多更大的名称集在文件系统而不是只有一个二进制文件。此外，您可以通过单个文件名调用功能，例如git-status和git-diff，或者您可以通过主git二进制文件使用多级命令，例如git status和git diff。
所以我建议即使在Unix世界中这也是一种公认的做法已经有一段时间了，你不应该因为与Unix哲学冲突而放弃这些建议。
答案 1 :(得分：0)
您可以通过指向可执行文件的符号链接在某种程度上充分利用这两个世界，并检查ARGV [0]的行为。
如果没有必要或打算单独升级这些工具，那么我认为将它们放在一个程序中是最好的方法。我认为这适用于工具密切相关的问题，就像您在示例中提到的那样。
这并不违反unix理念，ls有一大堆选项可以改变它的行为，理论上你可以将它放入单独的程序中。但是它们共享列出目录内容的共同功能，因此它们都在同一个可执行文件中。
但是如果函数在很大程度上是分开的（即ls和cat）并且可以合理地单独升级，那么将它们放在单独的可执行文件中可能是合适的。