构建一个Haskell项目，以便用户友好地处理“插件”

Question

问题是如何构建Haskell项目以便允许库的用户提供自己的插件而无需将自己的代码混合到库的源代码中。让我详细说明......

假设我有一个名为foolib的库

• 通过Plugin类型
提供插件
• 提供了一些（许多）类型，它们是Plugin类
的实例
• 应允许用户创建自己的插件

当然foolib的用户可以在foolib/内添加更多插件。但foolib的开发独立于使用foolib的应用程序，并且两者都在单独的SCM下。在这种情况下，在foolib/下混合用户的插件会违反分离并使源代码控制变得复杂。简而言之：当然，在foobar/中混合使用用户的插件是可行的，但无法维护。

明显的替代方案如下所示。用户维护my-project，将foolib/添加为git子模块（假设我们正在使用 git ），并将其插件保存在单独的Plugins/目录中。现在出现了两难境地：所有插件，即用户的插件和foolib中的插件，都在foolib/src/Core/的深处使用并重新暴露给用户 - 不是直接暴露，而是伪装。 （假设插件是CMS中的块，其中插件呈现一些HTML并使一些关键字可用，最终用户可以在其内容中使用，并且HTML模板引擎可以理解这些关键字。）< / p>

一个问题是如何让Haskell stack处理此设置，同时保持my-project/和foolib/的分离。

更糟糕的是，有一些模板Haskell（“TH”）继续在编译时发现foobar/src/Plugins中的所有插件并在源代码中的许多地方使用许多插件的类函数foolib。 （这还不完美，因为据我所知，进口不能被模板化 - 但这是另一个问题。）

我认为很明显，我在这里展示的结构不起作用，我看不出一个好的出路。中心问题是我要么牺牲foolib和my-project的分离，要么最终得到模板Haskell，sed，awk和其他脚本的卷积，这是最终适得其反。

非常感谢任何指导。

Answer 1

查看 Snap 框架非常有用，因为他们使用 snaplet 框架处理了这个问题。 Snaplet是在外部开发的，而Snap是在外部开发的。如果要创建Snap网站，可以将snaplet 和导入到应用程序中，然后将它们一起实例化。

http://snapframework.com