这里有人有使用Common Lisp作为嵌入式语言的经验（使用ECL）吗？如果是这样，与Lua相比，ECL有多好？
答案 0 :(得分：24)
我之前没有嵌入过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很强大，但我认为它对于嵌入来说太大了。
答案 1 :(得分：0)
我只能同意 Lua 很糟糕。当您拥有纯命令式函数式编程风格时，它运行良好，但如果您尝试使用大层次结构的 OO，则不行，例如，永远不要尝试在 Lua 层次结构中包装像 GTK 这样的典型 GUI 工具包，性能会很糟糕。
我仍然使用 Lua，因为它非常轻量级，您可以同时运行数十个解释器，并且最终用户理解使用它编写代码片段，而 Lisp/Scheme 则只有专家（缺乏）语法。
我现在要补充一点，mruby 3.0 已经发布，并且是一种非常好的嵌入语言。不幸的是，在此期间，每个人都只使用 Javascript 和 Javascript。