Lisp 作为 C++ 应用程序中的脚本语言 [关闭]答案

【问题标题】：Lisp as a Scripting Language in a C++ app [closed]Lisp 作为 C++ 应用程序中的脚本语言 [关闭]
【发布时间】：2009-11-11 16:38:56
【问题描述】：

嘿，我一直在考虑将脚本语言添加到我的框架中的可能性，我听说了 Lisp，并认为我会尝试一下。是否有像 Lua 和 Python 这样的 Lisp 虚拟机，还是我的心态错误。我在这里找到了 CLISP，http://clisp.cons.org/，但不确定这是否是我要找的。p>

谁能指出我正确的方向？

【问题讨论】：

CLISP 只是一个符合标准（具体来说是 ANSI）的 LISP 实现。
好的，那么这不是我想要的。我需要知道是否有 Lisp 的实现可以用作脚本语言。
如果你想让用户使用 lisp 作为你框架的接口，你必须讨厌他们。
@stimms，你的意思是，像 emacs？ ;-)
@stimms，是的，给你讨厌的用户一些合适的工具肯定意味着花更少的时间听他们对系统的抱怨

标签： c++ scripting lisp scheme common-lisp

【解决方案1】：

CLISP 只是 Common Lisp 的一种实现。这是一个非常好的实现，它确实支持嵌入到其他（基于 C 的）程序中，但这不是它的重点，它是 GPL 的，这对你来说可能会或可能不会破坏交易。

您可能有兴趣查看ECL。这个实现是专门为嵌入而设计的（实际上，“E”代表“Embeddable”！），并且具有许多可能对您有用的特性，包括将 Common Lisp 程序编译为 C 的能力（以及提供字节-代码编译和解释器）。

【讨论】：

由于您是第一个推荐它的人，所以我将您的标记为答案。对不起skypher =S
另一个不错的功能是可以从 REPL 调用 C/C++ 函数（非常适合测试它们）

【解决方案2】：

除非您需要整个 Lisp，否则您可能更愿意选择像 Guile 这样的 Scheme 实现，它旨在合并到另一个程序中。

【讨论】：

我之前的一份工作非常成功地为运行时脚本实现了一种类似于 Scheme 的语言。（我们不能仅仅出于内存和性能的原因使用 Guile，但它基本上是 Scheme 的一个子集。）
你几乎不需要整个 Common Lisp，这纯粹是夸张。相比之下，Scheme 是非常的准系统。

【解决方案3】：

尝试可嵌入的 Common Lisp (ECL)。

http://ecls.sourceforge.net/

它的目标是嵌入，并且您只获得您的脚本语言需要的 Common Lisp 部分链接。

【讨论】：

当前地址（你提到的那个暂时重定向到那里）是common-lisp.net/project/ecl

【解决方案4】：

Lisp 是嵌入式语言的不错选择。许多人认为 Lisp 很难，但语法相对较轻，尤其是对于非程序员而言。基本上有前缀符号，就是这样。优先规则总是明确的。函数名和变量名可以相同。您几乎可以随意使用任何您喜欢的字符来获得乐趣和 var 名称。

使用 Lisp，您可以根据自己的喜好调整语法； 用户不必学习普通的 lisp。它易于扩展和提供更简单的工具，例如表达业务规则或从文件中提取数据。

我想我的意思是说 Common Lisp 的强大和复杂性，可以为最终用户提供简单的、特定于领域的构造。许多其他嵌入式语言将意味着那些用户学习该语言的复杂性。

【讨论】：

有趣的是，我实际上为嵌入和嵌入式设备实现了自己的基本 lisp 环境：github.com/wentbackward-org/lisp_mu

【解决方案5】：

Chicken Scheme 是另一种嵌入选项。可嵌入api的详细信息请参见here。

【讨论】：

【解决方案6】：

有几个简单的选择。

GUILE 是 GNU 扩展语言。它是一个可嵌入的方案（LISP 的方言）。 GPL（自然）。

TinyScheme 是一个非常小、非常简单的基于解释器的 Scheme 实现。一家恶意软件公司成功地使用它来做各种令人讨厌的事情。它以源代码的形式提供，我不记得在什么许可证下。

【讨论】：

【解决方案7】：

谷歌一下：Common Lisp as an Extension language

但请记住，与 Lua 或 Guile 不同，Common Lisp 并不是从一开始就设计为一种扩展语言。

一般建议：尝试使用真正让编写工作更轻松的扩展语言，并记住掌握 Lisp 以便您能够真正高效地使用它可能需要很长时间（而且周围没有多少人可以支持这么多括号 xD）。

【讨论】：

Guile 是Scheme 的实现，Scheme 也不是作为扩展语言设计的。如果你算上 Guile，你也应该算上 ECL。
Lisp 语言的实际好处是具有统一的语法，这使得它们比具有传统语法的语言更容易理解和使用。没有运算符优先级或许多有趣的字符需要记住。
@Chris，好吧，Scheme 不是作为扩展语言设计的，但它非常小，非常适合用作嵌入式语言。另一方面，Common Lisp 是巨大的。这并不意味着它不能被嵌入，但是拥有像 CL 这样大的“脚本”语言毫无意义。我会喜欢使用 Java 作为“脚本”语言......当然它以前已经做过（我记得游戏吸血鬼：化妆舞会现在），但我仍然认为两者都很复杂且足够大，足以成为主要的编程语言，而不是扩展语言。
@skypher 我希望你是在开玩笑，因为如果你让任何非 lisper 来决定在 (+ 2 (* 5 3)) 和 2 + 5*3 之间什么更易读，我敢打赌答案将是第二个有概率的99%。关于有趣的字符，让我回忆一下引号、反引号、逗号、引号和哈希...不，明确地，易于理解代码并不是我所说的使用 Common Lisp 的优势。
@fortran：我觉得这里没有玩笑。前者在每种 Lisp 方言中的计算结果为 17，而后者为 17 或 21，具体取决于您使用的 ALGOL 派生语言。除了算术，几乎每一种语言都是前缀，如果你真的需要的话，我用过的大多数 Lisps 都有一个中缀表达式函数。（此外，一个典型的程序多久做一次算术？你的级别越高，你需要的就越少：我发现典型 C# 代码中的算术比 Java 中的少，两者都远低于 C，即使对于同样的任务。）

【解决方案8】：

由于不是 Lisp，Fuzuli 的语法类似于 Lisp。很容易将它集成到 C++ 应用程序中。官网是http://www.fuzuliproject.org

另一个是 http://www.newlisp.org/ 的 newLISP，它也不是 Lisp，但非常接近 Lisp。

【讨论】：

他确实要求使用 Lisp，但也许这些对他来说会更好。与 ECL 或 GUILE 相比，它们有什么优势吗？
作为 Fuzuli 的主要开发者，我不能客观，但我可以肯定地说它是轻量级的，学习曲线更陡峭，另外，速度可以满足需要应用程序中的脚本语言。尝试link 中的在线示例可能会对符号、语言和速度有所了解。
@jbytecode 我看过 Fuzili，它似乎是一个具有挑战性的项目。但实际上，现在的 GPL 绝对不适合库（我们谈论嵌入）。
好吧，你是对的。我们会将许可证更改为 LGPL。

【解决方案9】：

Lisp 是一个语言家族。

Common Lisp 是一个巨大的 ANSI 标准。认为 C++ 巨大。不要将其用作脚本语言。

除非你的目标是相当铁杆的程序员，否则 Lisp 作为一种脚本语言将会......呃......不太受欢迎。可能。 Lua 作为脚本语言可能是更好的选择。

也就是说，Lisp 可以（技术上）实现脚本语言。

【讨论】：

Clisp 不是一种语言，Clisp 是 Common Lisp 的一种实现。 Common Lisp 是一种语言，具有 ANSI 标准。一些应用程序正在使用 Common Lisp 作为脚本语言 - 尤其是那些需要重要扩展的应用程序，例如复杂的 CAD 系统。
Clisp 是 ANSI Common Lisp 的具体实现；同一标准语言还有大量其他实现。
@Rainer：是的，非平凡的可扩展性意味着普通的 lisp 或类似大小的语言将满足应用程序的需求。这有点取决于。大多数应用程序不需要成熟的编程语言插件系统。
问题是关于一些类似于 Lua 和 Python 的 Lisp VM。像 ECL 这样的常见 Lisp 实现就在那个联盟中。如果他想要 Python，他也可以使用 ECL 之类的实现。
你还没有真正给出避免使用 Common Lisp 的理由。例如 CLISP，Common Lisp 的一种实现（或 VM）大约为 5MB。