创建调用 OCaml 或 Haskell 的 GUI 桌面应用程序——这是一件傻事吗？
在 Haskell 和 OCaml 中，都可以从 C 程序调用该语言。为 Windows、Mac 或 Linux 创建广泛使用此技术的本机应用程序有多可行？
（我知道有像 wxHaskell 这样的 GUI 库，但假设有人只想用外语编写应用程序逻辑的一部分。）
或者这是一个糟糕的主意？
In both Haskell and OCaml, it's possible to call into the language from C programs. How feasible would it be to create Native applications for either Windows, Mac, or Linux which made extensive use of this technique?
(I know that there are GUI libraries like wxHaskell, but suppose one wanted to just have a portion of your application logic in the foreign language.)
Or is this a terrible idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
嗯，主要的风险是，虽然设施存在，但它们没有经过充分的测试——没有很多应用程序这样做。从 C 调用 Haskell 应该不会有太多麻烦，看起来很简单：
http://www.haskell.org /haskellwiki/Calling_Haskell_from_C
我想说的是，如果有一些令人信服的理由使用 C 作为前端（例如，您有一个遗留应用程序）并且您确实需要一个 Haskell 库，或者出于其他原因想要使用 Haskell ，那么，是的，去做吧。主要风险在于没有很多人这样做，因此与调用其他方式相比，文档和示例更少。
Well, the main risk is that while facilities exist, they're not well tested -- not a lot of apps do this. You shouldn't have much trouble calling Haskell from C, looks pretty easy:
http://www.haskell.org/haskellwiki/Calling_Haskell_from_C
I'd say if there is some compelling reason to use C for the front end (e.g. you have a legacy app) and you really need a Haskell library, or want to use Haskell for some other reason, then, yes, go for it. The main risk is just that not a lot of people do this, so less documentation and examples than for calling the other way.
您也可以将 OCaml 嵌入到 C 中（请参阅手册 ），尽管这并不像用 C 扩展 OCaml 那样常见。
You can embed OCaml in C as well (see the manual), although this is not as commonly done as extending OCaml with C.
我相信，即使 GUI 和逻辑都是用同一种语言编写的，最好的方法是运行两个进程，通过人类可读的、基于文本的协议（某种 DSL）进行通信。该架构也适用于您的情况。
优点是显而易见的：GUI是可拆卸和可替换的，自动化测试更容易，日志记录和调试更容易。
I believe that the best approach, even if both GUI and logic are written in the same language, is to run two processes which communicates via a human-readable, text-based protocol (a DSL of some sort). This architecture applies to your case as well.
Advantages are obvious: GUI is detachable and replaceable, automated tests are easier, logging and debugging are much easier.
我通过编译在 Haskell 外部调用的 haskell 共享库来广泛利用这一点。
通常涉及的任务是
机械化且结构化，以至于您可以编写一些东西来自动化它们。事实上，我自己使用的是我创建的一个工具，它对您标记为导出的函数进行依赖项跟踪，它会将它们包装起来并为您编译共享库，同时为您提供 C/C++ 中的声明。
（不幸的是，这个工具还没有被破解，因为在我习惯这样做之前，我仍然需要修复和测试更多的东西）工具可以在这里使用 http://hackage.haskell.org/package/Hs2lib-0.4.8
I make extensive use of this by compiling haskell shared libs that are called outside Haskell.
usually the tasks involved would be to
These tasks are rather robotic and structured, to a point you could write something to automate them. Infact what I use myself to do this is a tool I created which does dependency tracing on functions you marked to be exported, and it'll wrap them up and compile the shared lib for you along with giving you the declarations in C/C++.
(unfortunately, this tool is not yet on hackage, because there is something I still need to fix and test alot more before I'm comfortable doing so)Tool is available here http://hackage.haskell.org/package/Hs2lib-0.4.8
这根本不是一个可怕的主意。但正如唐·斯图尔特指出的那样，这可能是一条少有人走的路。你当然可以以 Haskell 或 OCaml 的形式启动你的程序，然后让它从一开始就进行外部函数调用——我建议你以这种方式构建你的代码——但这并不能改变更多人调用的事实从 Haskell 到 C 比从 C 到 Haskell 好。 OCaml 也是如此。
It's not a terrible idea at all. But as Don Stewart notes, it's probably a less-trodden path. You could certainly launch your program as Haskell or OCaml, then have it do a foreign-function call right out of the starting gate—and I recommend you structure your code that way—but it doesn't change the fact that many more people call from Haskell into C than from C into Haskell. Likewise for OCaml.