这里有没有人使用ECL将Common Lisp作为嵌入式语言的经验?如果是,那么ECL与Lua相比如何?
这里有没有人使用ECL将Common Lisp作为嵌入式语言的经验?如果是,那么ECL与Lua相比如何?
我之前没有嵌入过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时,它总是首先将该代码编译为字节码,然后再运行它)。
现在,就通用Lisp而言,我认为它可能不适合作为嵌入式语言。原因就是CL非常庞大。通常,嵌入式语言应该是轻量级的,因为它将使用由您提供的平台/库,而不是太多外部的东西。
所以,我认为无论选择Gambit-C,Guile还是Lua都不会有错。它们都很好用。CL功能强大,但我认为它对于嵌入式来说实在太大了。
我完全同意Lua很糟糕这一点。当你使用纯命令式函数编程风格时,它可以很好地工作,但如果你尝试使用大型层次结构的面向对象编程,例如永远不要尝试在Lua层次结构中包装典型的GUI工具包,如GTK,性能将非常糟糕。
我仍然使用Lua,因为它非常轻量级,可以同时运行数十个解释器,并且最终用户可以理解如何使用它编写代码片段,而Lisp / Scheme则需要专家才能掌握(缺乏)语法。
现在我想补充说,mruby 3.0已经发布,是一个很棒的嵌入式语言。不幸的是,在此期间,每个人都转向了JavaScript和仅JavaScript。