lua - 嵌入式语言：Lua vs Common Lisp (ECL)

Question

这里有人有将 Common Lisp 作为嵌入式语言（使用 ECL）的经验吗？如果是这样，ECL 与 Lua 相比有多好？

Answer 1

我以前没有嵌入 CL，但我已经使用 Lua 和两个特定的 Scheme 实现（Gambit-C 和 GNU Guile）完成了它。

在我看来，Scheme 是一种出色的嵌入式语言，因为它灵活且不太臃肿。Gambit-C 在这方面特别棒，因为它允许您运行解释脚本，还可以将代码编译成 C。在我的测试中，Gambit-C 生成的 C 代码只比手写 C 慢一点（例如，在 C 中运行 0.030 秒的特定测试在 Gambit 中是 0.040！）。Gambit 还有一个非常好的 FFI（外来函数接口），它本质上只是具有特殊语法的 Scheme，用于编写与 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，例如永远不要尝试将 GTK 等典型的 GUI 工具包包装在 Lua 层次结构中，性能将非常糟糕。

我仍然使用 Lua，因为它非常轻量级，可以同时运行数十个解释器，最终用户可以理解使用它编写代码片段，而 Lisp/Scheme 仅具有专家（缺乏）语法。

我现在要补充一点，mruby 3.0 已经发布，并且是一种很好的嵌入语言。不幸的是，与此同时，每个人都只使用 Javascript 和 Javascript。