如何为程序命名我的Haskell模块，而不是库，在层次结构中组织它们？
我正在拍摄一部名为Luminosity的光线追踪器。首先我有这些模块：
Vector Colour Intersect Trace Render Parse Export
每个模块都很好，但我觉得这个组织缺乏。
首先，我将每个模块放在Luminosity下，所以例如Vector现在是Luminosity.Vector（我认为这是haskell程序的标准？）。
然后我想：矢量和颜色是独立的并且可以重复使用，因此它们应该分开。但它们太小而无法变成图书馆。
他们应该去哪儿？已经（在hackage上）Data.Vector和Data.Colour，我应该把它们放在那里吗？或者这会引起混淆（即使我将它们与我的其他本地导入一起导入）？如果不存在，应该是Luminosity.Data.Vector还是Data.Luminosity.Vector？我很确定我已经看过两个都使用了，虽然我可能只是碰巧看一个使用非传统结构的项目。
我还有一个简单的TGA图像导出器（Export），可以独立于Luminosity。看来正确的位置是Codec.Image.TGA，但是，Luminosity应该在某处，如果是，那么在哪里？
如果Structure of a Haskell project或其他一些维基解释了这一点，那就太好了。
答案 0 :(得分：19)
除非你的程序真的大，否则不要在层次结构中组织模块。为什么不呢？因为虽然计算机擅长层级，但人们却不是。人们擅长有意义的名字。如果选择好的名称，您可以在平面名称空间中轻松处理150个模块。
我觉得[平面名称空间]缺乏组织。
分层组织本身并不是目的。要证明将模块拆分为层次结构是合理的，您需要原因。好的理由往往与信息隐藏或重用有关。当您引入信息隐藏时，您正处于图书馆设计的一半，当您谈论重用时，您正在有效地构建库。将大型程序转换为“较小的程序加库”是软件 evolution 的一个很好的策略，但看起来你刚刚开始，而你的程序还不够大，无法进化
这些问题很大程度上与您使用的编程语言无关。我建议阅读David Parnas关于产品线和程序系列的一些工作，以及Matthias Blume的低估文章Hierarchical Modularity。这些工作将为您提供关于何时层级开始服务于目的的更具体的想法。
答案 1 :(得分：11)
首先，我将每个模块放在
下Luminosity
我认为这是一个很好的举措。它向正在阅读代码的任何人澄清这些模块是专门为Luminosity项目制作的。
如果您编写的模块旨在模拟或改进现有库，或者填补您认为缺少特定通用库的空白，那么在极少数情况下，请删除前缀并将其命名为泛型。有关此示例，请参阅pipes包如何导出Control.Monad.Trans.Free，因为无论出于何种原因，作者对Free monad的现有实现都不满意。
然后我想，Vector和Color几乎是独立的，可以重复使用，因此它们应该分开。但是它们很小，可以分成一个库（分别为125和42行）。他们应该去哪儿？
如果您没有创建单独的库，则可能将它们保留在Luminosity.Vector和Luminosity.Colour。如果您确实创建了单独的库，那么请尝试通过电子邮件发送这些库的目标受众，并了解其他人如何认为这些库应该被命名和分类。您是否将这些文件拆分为单独的库完全取决于您以及您认为这些单独的库可能为其他人提供的好处。