Haskell 模块命名约定

Question

我应该如何为程序而不是库和 命名我的 Haskell 模块将它们组织成层次结构 ?

我正在制作一个名为 Luminosity 的光线追踪器。首先我有这些模块:

Vector Colour Intersect Trace Render Parse Export

每个模块本身都很好，但我觉得这缺乏组织。

首先，我把每个模块都放在 Luminosity 下。 ，例如 Vector现在是 Luminosity.Vector (我认为这是 haskell 程序的标准？)。

然后我想:Vector和Color是独立的，可以复用，所以应该分开。但是它们太小了，不能变成图书馆。

他们应该去哪里？已经有(在 hackage 上)一个 Data.Vector和 Data.Colour ，所以我应该把它们放在那里吗？或者这会导致混淆(即使我将它们与其他本地进口组合进口)？如果没有，应该是 Luminosity.Data.Vector或 Data.Luminosity.Vector ?我很确定我已经看到两者都使用过，尽管也许我只是碰巧看到了一个使用非常规结构的项目。

我还有一个简单的 TGA 图像导出器 ( Export)，它可以独立于 Luminosity。正确的位置似乎是 Codec.Image.TGA ，但同样，应该 Luminosity在某个地方，如果是，在哪里？

如果 Structure of a Haskell project就好了或其他一些维基解释了这一点。

Answer 1

除非你的程序真的很大，不要按层次结构组织模块。 为什么不？因为尽管计算机擅长等级制度，但人却不擅长。人们擅长有意义的名字。如果您选择好的名称，您可以轻松地在一个平面 namespace 中处理 150 个模块。

I felt like [a flat name space] lacked organization.

等级组织本身并不是目的。为了证明将模块分成层次结构是合理的，您需要一个理由。好的理由往往与信息隐藏或重用有关。当您引入信息隐藏时，您就完成了库设计的一半，而当您谈论重用时，您实际上是在构建库。将一个大程序变成“小程序加库”是软件进化的一个好策略，但看起来你才刚刚开始，而且你的程序还不够大，无法以这种方式进化。

这些问题在很大程度上与您使用的编程语言无关。我建议阅读 David Parnas 的一些关于产品线和程序系列的著作，以及 Matthias Blume 的未获认可的论文 Hierarchical Modularity .这些作品将为您提供一些关于等级何时开始服务于目的的更具体的想法。