为什么在llvm上没有一个好的方案/ lisp？

Question

有Gambit计划,麻省理工学院计划,PLT计划,鸡计划,Bigloo,Larceny,......; 然后有所有的lisps.

然而,就我所知,LLVM上没有(据我所知)一个流行的方案/ lisp,即使LLVM提供了很多很好的东西,比如:

• 比x86更容易生成代码
• 容易做出C FFI调用......

那么为什么LLVM上没有一个好的方案/ lisp呢？

Answer 1

LLVM提供了很多,但它仍然只是函数式语言所需的运行时的一小部分.并且C FFI调用并不复杂,因为LLVM使内存管理由其他人处理.交互垃圾收集器是使用诸如Scheme之类的语言使FFI调用困难的原因.

您可能对HLVM感兴趣,但此时它仍然不仅仅是实验性的.

Answer 2

这里有一个非常小且显然未被优化的Scheme编译器:

http://www.ida.liu.se/~tobnu/scheme2llvm/

从字面上理解你的问题,

• 编写编译器很难.
• 像上面链接的那样糟糕的实现可以阻止新的实现.进入LLVM页面的人看到已经有一个Scheme,并且不打算写一个.
• 编写和使用Scheme的人数有限(我是一个,不是仇恨,顺便说一句).
• 有很多现有的Scheme解释器和编译器,并没有尖叫的需要有一个新的.
• 使用LLVM编写新的解释器并没有立竿见影的明显好处.它会比其他几十个Scheme实现更快,更容易,更灵活,更好吗？
• LLVM项目使用另一种语言(C)来演示他们的技术,并且没有看到需要实现许多其他语言.

我认为有人建立一个基于LLVM的Scheme编译器会很有趣.SICP和PAIP中的Scheme编译器都是很好的例子.

Answer 3

对于CL:Clasp是LLVM上的Common Lisp实现,mocl在LLVM上实现Common Lisp的子集.

对于Scheme:有一个自托管Scheme-> LLVM演示和Bigloo Scheme的原型LLVM后端.

对于Clojure:莱茵河,这是一个受Clojure启发的口齿不清.

Answer 4

要记住的一件事是,许多这些实现都有C FFI和本机代码编译器,它们远远早于LLVM.

Answer 5

也许我完全误解了问题或上下文,但我相信你可以使用ECL,它是一个编译为C的Common Lisp,并使用Clang编译器来定位LLVM(而不是GCC).

我不确定这会给你带来什么(如果有的话),但它会给你一个在LLVM上运行的Lisp =].

Answer 6

CL-LLVM为 LLVM 提供 Common Lisp 绑定。它采用 FFI 方法，而不是尝试直接输出 LLVM 程序集或位码。

该库可通过 Quicklisp 获得。