Lisp 作为元环境答案

【问题标题】：Lisp as a meta environmentLisp 作为元环境
【发布时间】：2012-05-22 21:12:04
【问题描述】：

我正在攻读博士学位，通过集成不同类型的计算机语言来更好地重用软件。由于性能和安全问题，我不考虑将它们与外部函数调用和/或 Web 服务的使用集成。

Lisp 是我最喜欢的工具，因为它包含交互式开发、宏、在运行时进行修改、代码即数据（人们通常会想象听到 Lisp 这个词）等等。有一些方法可以将不同类型的 Lisp 移植到 JVM（clojure、kawa、SISC、ABCL 等）或 .NET（clojure .NET、DotLisp、IronLisp）等虚拟机上。这很有趣，但仅限于相应虚拟机的“宇宙”。

有谁知道相反的方法，即在 Lisp 系统上运行 Java 或 C#？我找到了斗篷的其余部分。这似乎或多或少是一个死项目。对我来说，将 Lisp 作为一种通用抽象来托管其他语言（如 Java 和 C#）会更明智。

您认为在克服缺乏通用且可扩展的“语言环境”集成 Java 或 C# 等语言（没有外部函数调用或（Web）服务）方面存在哪些障碍？是因为没有 Lisp 系统在某种虚拟机上运行，例如 LLVM，还是其他原因？

最好的问候，英格玛

【问题讨论】：

你为什么要运行例如lisp 虚拟机中的 C#？
如果您有实际的软件相关问题，请在此处提问。如果您的问题更笼统，请使用 programmers.stackexchange.com 。请参阅 stackoverflow 常见问题解答。
在 Let Over Lambda 中有一个 Forth 转编译器到 Common Lisp 的示例，还有一个 Python 代码转换（转编译器）到 Common Lisp 作为 CLPython。如果您还没有，可能值得您花时间检查一下。
为什么喜欢在一个平台上运行 SCALA、Java 和 Ruby？因为需要为一个项目集成这些语言。没有灵丹妙药，不同的语言解决不同的问题。此外，我们拥有任何语言的数万亿行代码。为什么不重复使用它们？与其每隔几年重新发明轮子，不如将这些程序集成起来更有意义，这已经部分实现了，但你必须遵守其中一个大型 VM（Java 和 .NET）的规则。
VM 是集成异构语言运行时的媒介，任何给定 VM 的单一宿主语言都无法替代它们。否则（例如，使用 SBCL 或任何其他本机 Lisp），您将必须专门为每个语言对处理 FFI 和编组。而且，.NET 并没有那么糟糕——它也可以处理 JVM（参见 IKVM）。

标签： lisp metaprogramming environment

【解决方案1】：

Lisp 因其宏功能而成为这种语言托管的良好平台。但是，您需要更多的语言特性来做好它：模块、阅读器宏、高级宏规范等等。 Racket 是一个朝着这个方向发展的 Lisp 变体。您已经可以使用Algol 60、Prolog 的变体、typed sister language 等等。 Guile 也在朝着这个方向发展，实现了 ECMAScript。

就在 Lisp 上实现 Java 或 C# 而言，理论上是可行的，但需要大量工作才能在实际水平上支持这些语言（Racket 用于实现一小部分 Java）。考虑到 CLR 和 JVM 现在都是多语言平台，您是否真的会有所收获也不清楚。更有趣的是利用 Lisp 宏来定义更好的自定义语言 (DSL)，定义有用的 Lisp 方言，或者专门实现另一种语言来引导有用的工具（例如，Guile 实现 Emacs Lisp）。

【讨论】：

【解决方案2】：

“这取决于”，一如既往，对吧？

如果有的话，您希望向 Java 公开多少 Lisp？例如，如果您将 JVM 移植到 Lisp，您是否以某种方式将垃圾收集器所需的 JVM 与 Lisp 实现的实际底层 GC 相匹配，或者您只是编写自己的 GC 来 GC JVM 堆中的 JVM 对象。

出于多种原因，将两者结合起来很可能是不切实际的。 Lisp GC 在实际实现中几乎是隐藏的，就像 Javas GC 一样。这可能太隐蔽而无法与 JVM 实现一起使用。

没有理由不能在 Lisp 中构建 JVM，它只是一堆字节码。 Lisp 可以很好地处理字节。

已经有 JVM 在 JavaScript 中的实现，它与核心的 Lisp 没有太大区别。

但除了有一个 lispy 命令行与 JVM 交互之外，JVM 本身不会很“lispy”。怎么会这样？这是一个 JAVA 虚拟机。实现可以是“lisp”，但理想情况下，这种 lisp-ness 不会冒泡到 JVM 本身。

除了 Lisp 在开发任何程序方面的任何优势之外，我认为 Lisp 并不特别适合“更好”地开发虚拟机。

Lisp 擅长开发其他语言，尤其是其他基于 S-Exp 的语言。但是虚拟机就是虚拟机。 Monster case 语句或其他基于数值机制的调度。

【讨论】：

Lisp 非常适合开发编译器，而 JVM JIT 确实是一个编译器。所有的事情，从带有模式匹配的简单“纳米通道”，到实现 SSA 转换、寄存器调度和指令选择，如果在 Lisp 中实现（或者更好的是，在嵌入到 Lisp 中的 DSL 之上）都非常好和干净。但是，当然，这个编译器不应该以 Lisp 本身为目标。

【解决方案3】：

Lisp 是这样一个元平台的完美宿主语言，但它不一定是编译低级和命令式的理想目标语言。幸运的是，没有什么能阻止您在 Lisp 环境中生成汇编代码。

【讨论】：

非常感谢，确实像 C 这样的语言在垃圾收集器方面有些不合作。除了提到的小而过时的项目cloak之外，我的需求目标是针对为什么正在进行的开发工作如此之少的原因。对于这种语言环境，我认为 LLVM 将是一个非常有趣的平台，当然基于 Lisp。 LLVM 比 JVM 低得多，因此应该可以通过 Lisp 生成器生成位码。
@metaman，垃圾收集是异构系统中的小问题。 FFI 和编组更糟糕。这就是为什么那些“统一”的虚拟机如此受欢迎的原因。它们是有限的和限制性的，但它们为在上面运行的所有语言提供了通用 ABI 和通用数据结构表示。 LLVM 不会轻易解决这个问题。顺便说一句，感谢cloak 链接，这很有趣。