创建调用OCaml或Haskell的GUI桌面应用程序-这是一件蠢事吗?

我通过编译haskell共享lib(在haskell外部称为lib)来广泛地利用这一点。

通常所涉及的任务是

2. 为需要封送的任何数据类型创建可存储实例
3. 创建C结构(或您正在使用的语言中的结构)来读取此信息
4. 因为我不想手动初始化haskell RTS,所以我将初始化/终止代码添加到lib本身(dllmain in windows\uu属性(unix上的构造函数)
5. 因为我不再需要它们中的任何一个,所以我创建了一个.def文件来隐藏导出表(windows)中的所有闭包和rts函数
6. 使用GHC将所有内容编译在一起

这些任务是相当机器人化和结构化的,以至于你可以写一些东西来自动化它们。事实上,我用我自己来做的是一个工具,它创建了对你标记的函数进行依赖跟踪,并将它们打包并编译共享库,并给出C/C++中的声明。

(不幸的是,这个工具还没有被黑客攻击,因为我还需要修复一些东西并进行更多的测试,然后才能放心地这么做)

工具在这里可用 http://hackage.haskell.org/package/Hs2lib-0.4.8

http://www.haskell.org/haskellwiki/Calling_Haskell_from_C

我想说,如果有一些令人信服的理由使用C作为前端(例如,你有一个遗留的应用程序),并且你真的需要Haskell库,或者出于其他原因想使用Haskell,那么,是的,去做吧。主要的风险是没有很多人这么做,所以比起用另一种方式来调用,文档和示例更少。

您也可以在C中嵌入OCaml(参见 the manual

我相信最好的方法,即使GUI和逻辑都是用同一种语言编写的,也是运行两个进程,通过一个可读的、基于文本的协议(某种DSL)进行通信。这种架构也适用于您的案例。

或者这是个糟糕的主意?

这个主意一点也不可怕。但正如唐·斯图尔特所说,这可能是一条不那么受人践踏的道路。当然,您可以以Haskell或OCaml的形式启动程序,然后让它在启动门外执行一个外部函数调用,我建议您以这种方式构造代码,但这不会改变这样一个事实:从Haskell调用C的人比从C调用Haskell的人多。OCaml也是如此。