在选择用于 LLVM 的函数式编程语言时，有哪些取舍？答案

【问题标题】：When choosing a functional programming language for use with LLVM, what are the trade-offs?在选择用于 LLVM 的函数式编程语言时，有哪些取舍？
【发布时间】：2010-12-18 22:27:57
【问题描述】：

让我们暂时假设 C++ 不是函数式编程语言。如果您想为后端使用 LLVM 编写编译器，并且您想使用函数式编程语言及其与 LLVM 的绑定来完成您的工作，据我所知，您有两种选择：Objective Caml 和 Haskell。如果还有其他的，那我也想知道。

我不是在征求主观意见，所以请不要给这个subjective 标签。我想对此做出自己的决定，但我不确定我是否知道所有的权衡取舍。所以，StackOverflow 来救场了。有哪些取舍？

【问题讨论】：

“让我们暂时假设 C++ 不是函数式编程语言。”它从来没有是一个。
开个玩笑。
dons cmets 下面将我带到这篇关于 Haskell LLVM 绑定的博客文章，它涵盖了我想从 Haskell 方面了解的很多内容：augustss.blogspot.com/2009/01/…
所以，我现在注意到的一件事是，我正在深入研究这个问题，即与 LLVM 一起分发的 OCaml 和 Ada 绑定基本上只是 LLVM C- 上的薄包装器语言子集。 Haskell 绑定由我的朋友 Bryan O'Sullivan 编写，在 LLVM C 语言子集的 FFI 包装器之上添加了一个非常特定于 Haskell 的 API。
当然，conal.net/blog/posts/the-c-language-is-purely-functional

标签： haskell functional-programming ocaml llvm

【解决方案1】：

OCaml 或 Haskell 都是不错的选择。为什么不查看每种语言的 LLVM 教程？ OCaml 的 LLVM 教程在这里：http://llvm.org/docs/tutorial/OCamlLangImpl1.html

Haskell 近来势头强劲，但也有很多优秀的 OCaml 解析库，包括 PEG 解析器生成器 Aurochs、Menhir 和 GLR 解析器生成器 Dypgen。还可以查看有关 pcl 的演示文稿，一个用于 OCaml 的单子解析器组合库（例如用于 Haskell 的 Parsec），其中有一些比较 Haskell 和 OCaml 方法的好信息：http://osp.janestreet.com/files/pcl.pdf

有些人会说惰性使 Haskell 在解析方面具有优势，但您也可以在 OCaml 中获得惰性。

【讨论】：

有没有 Haskell/LLVM 教程？
哦，我的 OCNAE Cf 库中的一元解析器组合器是我在 OCaml 中首选的解析解决方案。我看着 Parsec，很失望。如果我使用 Haskell，我可能会在做其他任何事情之前将我的 Cf 库移植到它。
@james augustss.blogspot.com 有一系列关于 LLVM 绑定的文章，包括示例。 LLVM 绑定还有其他几个用户（原型 GHC 后端和 lambda 演算编译器，blog.finiteimprobability.com/2009/11/17/…
@dons 谢谢！这就是我希望得到的信息！

【解决方案2】：

与 OCaml 相比，Haskell 对 LLVM 的绑定级别更高（Haskell 提供了一些有趣的类型安全保证），而且 Haskell 有更多的库可供使用（http://hackage.haskell.org 上有 1700 个包），从而更容易将组件粘合在一起。

【讨论】：

"...一些有趣的类型安全保证..." 我想了解更多。
augustss.blogspot.com/2009/01/… 有一个概述。

【解决方案3】：

OCaml 是唯一具有 bindings in the LLVM distro itself 和 llvm.org 上的文档（例如 Kaleidoscope tutorial）的函数式语言。如果您在构建和安装 LLVM 时安装了 OCaml，那么它也会自动构建和安装 OCaml 的 LLVM 绑定。此外，这些 OCaml 绑定是in use for years，因此它们成熟可靠。

我一直在使用标准 LLVM 绑定在 OCaml 中开发 HLVM，发现 OCaml+LLVM 是一个非常强大的组合。 HLVM 提供元组、数组、联合、所有尾调用的 TCO、通用打印、FFI 到 C、JIT 编译和并行垃圾收集，其中一个 VM 重量低于 2kLOC 的 OCaml 代码，从头开始开发只需要几个人工周. HLVM's numerical performance already far exceeds that of today's fastest open source FPLs including OCaml itself。我已经发布了articles in the OCaml Journal，描述了如何从 OCaml 中将 LLVM 用于从基本表达式评估到并行性和垃圾收集等高级主题的所有内容。你可能也喜欢这个mini example。

【讨论】：

但是 OCaml 并不是唯一绑定到 LLVM 的函数式语言。 Haskell 可以编译为 LLVM (cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM)。 OCaml 绑定只是作为示例发布。
@jetxee：不，OCaml 绑定不仅仅是作为示例提供的。它们用于基于 LLVM 的工业项目以解决实际问题。 AFAIK，Haskell 绑定是不完整的、不成熟的，并且从未对它们做过任何重要的事情。您引用的 Haskell->LLVM 编译器实际上使用文本接口而不是二进制绑定来生成 LLVM IR。
LLVM 绑定在 Lennart 为他的雇主编写的软件中用于商业用途 - 事实上，作为函数式编程语言的代码生成层。我确信它们非常健壮，尽管它们确实可能缺少一些深奥的功能。
@Max：很有趣。你知道 Lennart 使用了哪些 LLVM 绑定吗？
他贡献的那些，我认为是规范的 Haskell 绑定到 LLVM。见hackage.haskell.org/package/llvm

【解决方案4】：

本机绑定的可用性不必限制您对语言的选择。除了使用绑定或直接生成 IR 文本之外，还有第三种选择：

您可以使用与语言无关的序列化格式（例如 Google 的协议缓冲区）作为从前端到后端的桥梁。毕竟，协议缓冲区只是伪装的 AST。

您的前端以函数式语言实现，然后执行其最擅长的工作 - 解析、类型检查、去糖、核心到核心转换等 - C++ 后端从您的前端获取 IR 并使用 LLVM 的 feature-complete-by-definition 本机 C++ API 来从 your-language-IR 降低到 LLVM IR。这使得处理 LLVM 的“高级”功能（例如调试元数据）变得更加容易。

我正在将此策略与 hprotoc 和协议缓冲区的相关 Haskell 绑定一起使用，并且我非常对结果感到满意。在工作中使用正确的工具有很多话要说！

【讨论】：

哇。这是我永远不会想到的想法。既然我已经接触过它，我不确定当你说“使用 [这个策略] 有很多话要说”时，假设我知道你的意思，我是否会感到安全。你能详细说明一下吗？
James，我不能 100% 确定您要详细说明什么……但最后一句话只是一般性观察，即某些工作最好使用一种以上的工具来解决，这并没有错。我认为人们有时会忘记使用一种以上的语言是可行的！