Haskell模块命名约定

Question

我应该如何为程序而不是库命名我的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在某处,如果是的话,在哪里？

如果Haskell项目的结构或其他维基解释了这一点,那就太好了.

Answer 1

除非您的程序非常大,否则不要在层次结构中组织模块. 为什么不？因为虽然计算机擅长层级,但人们却不是.人们擅长有意义的名字.如果选择好名称,您可以在平面名称空间中轻松处理150个模块.

我觉得[平面名称空间]缺乏组织.

分层组织本身并不是目的.要证明将模块拆分为层次结构是合理的,您需要一个理由.好的理由往往与信息隐藏或重用有关.当您引入信息隐藏时,您正处于图书馆设计的一半,当您谈论重用时,您正在有效地构建库.将大型程序变成"较小的程序加库"是软件演化的一个很好的策略,但看起来你刚刚开始,而你的程序还不够大,无法进化.

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

Answer 2

首先,我把每个模块放在下面 Luminosity

我认为这是一个很好的举动.它向正在阅读代码的任何人澄清这些模块是专门为该Luminosity项目制作的.

如果您编写的模块旨在模拟或改进现有库,或者填补您认为缺少特定通用库的空白,那么在极少数情况下,请删除前缀并将其命名为泛型.有关此示例,请查看管道包的导出方式Control.Monad.Trans.Free,因为无论出于何种原因,作者对Free monads的现有实现都不满意.

然后我想,Vector和Color几乎是独立的,可以重复使用,因此它们应该分开.但是它们很小,可以分成一个库(分别为125和42行).他们应该去哪儿？

如果你没有建立一个单独的库,那么可能将它们保留在Luminosity.Vector和Luminosity.Colour.如果您确实创建了单独的库,那么请尝试通过电子邮件发送这些库的目标受众,并了解其他人如何认为这些库应该被命名和分类.您是否将这些文件拆分为单独的库完全取决于您以及您认为这些单独的库可能为其他人提供的好处.