嵌入式语言: Lua vs Common Lisp (ECL)

Question

在座的任何人都有将Common Lisp作为嵌入式语言(使用ECL)的经验吗？如果是这样，ECL与Lua相比有多好？

Answer 1

我以前没有嵌入过CL，但是我用Lua和两个特定的Scheme实现(Gambit-C和GNU Guile)做到了。

在我看来，Scheme是一种很棒的嵌入式语言，因为它很灵活，而且不会太臃肿。在我的测试中，Gambit-C生成的C代码只比手写的C慢一点(例如，在C中运行0.030s的特定测试在Gambit！中运行了0.040 )。Gambit还有一个非常好的FFI (外部函数接口)，它本质上只是一个使用特殊语法编写C库绑定的方案(也直接支持ObjC和C++ )。Gambit也有一个非常好的repl，带有一些调试功能。

Guile也很不错，而且它实际上比Lua (据我所知的最快的解释语言-- Guile在最近几年取得了很大的进步)运行得更快。但是由于Gambit-C可以编译成非常快的代码，所以我通常不会经常使用Guile，除非我打算在最终版本中使用解释代码。

Lua有闭包，但是你不会像Scheme一样得到延续，你也不会得到宏。尽管如此，仍然可以做一些合理数量的函数式内容。它不会有一个功能齐全的对象系统(就像CL中的CLOS )，但它确实有表，而且它们可以很容易地实现基于类的继承和基于原型的继承。此外，Lua有一个很棒的C API，使用起来真的很愉快。它是基于堆栈的，并且以这样一种方式设计:您根本不必担心内存管理的Lua方面。API非常清晰，组织良好，有很多很好的文档和示例代码。Lua不能向下编译，但它确实使用了字节码(总是--当您向Lua VM发送代码时，它总是先将该代码编译为字节码，然后再运行它)。

现在，至于Common Lisp，我认为它可能不会成为一种很好的嵌入语言。这样做的原因只是因为CL很大。一般来说，嵌入轻量级语言是可取的，因为它将使用您提供给它的平台/库，而不是太多的外部东西。

因此，我认为使用Gambit-C、Guile或Lua都不会出错。他们都会很不错的。CL很强大，但我只是觉得它太大了，不适合嵌入。

Answer 2

我只能同意Lua很糟糕。当你有一个纯粹的命令式函数式编程风格时，它工作得很好，但如果你尝试用大型层次结构进行OO，例如，永远不要试图在Lua层次结构中包装像GTK这样的典型GUI工具包，性能将非常糟糕。

我仍然使用Lua，因为它是如此轻量级，以至于你可以同时运行几十个解释器，并且最终用户知道用它来编写代码片段，而Lisp/Scheme只有一个专家(缺乏)语法。

我现在要补充的是，mruby 3.0已经出来了，是一种很棒的嵌入式语言。不幸的是，在此期间，每个人都只使用Javascript和Javascript。