Lisp作为元环境

我正在攻读博士学位，通过集成不同类型的计算机语言来实现更好的软件重用。由于性能和安全问题，我不考虑将它们与外部函数调用和/或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，还是其他什么

---

值得一提的是，由于Ingmar的宏功能，它是一个很好的语言托管平台。但是，您需要更多的语言特性来做好这项工作：模块、读取器宏、高级宏规范，等等。是朝着这个方向发展的一种Lisp变体。您已经可以使用、的变体、等。也正朝着这一方向发展，并正在实施

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

那么“这取决于”，一如既往，对吗

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

出于几个原因，将两者结合起来很可能是不切实际的。Lisp-GC与Javas-GC非常相似，在实际实现中是隐藏的。这可能太隐蔽，无法与JVM实现一起工作

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

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

但是，除了有一个lispy命令行与JVM交互之外，JVM本身也不是很“lispy”。怎么可能呢？这是一个JAVA虚拟机。实现可以是“lispy”，但理想情况下，lisp的所有特性都不会对JVM本身产生影响

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

---

Lisp非常擅长开发其他语言，特别是其他基于S-Exp的语言。但是虚拟机就是虚拟机。Monster case语句或其他基于数值机制的分派。

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

为什么要在Lisp vm中运行例如C？如果您有实际的软件相关问题，请在此处提问。如果你的问题比较笼统，那么就使用。请参阅stackoverflow常见问题解答。这里有一个例子，在Let Over Lambda中有一个到Common Lisp的Forth transcompiler，还有一个到Common Lisp的Python代码转换（transcompiler）作为CLPython。如果你还没有的话，也许值得你花时间去看看。为什么人们喜欢在一个平台上运行SCALA、Java和Ruby？因为一个项目需要集成这些语言。没有银弹，不同的语言解决不同的问题。此外，我们在任何语言中都有万亿行代码。为什么不重新使用它们呢？与其每隔几年重新发明一次轮子，不如集成这些程序，这已经部分实现了，但你必须遵守其中一个大型虚拟机（Java和.NET）的规则。虚拟机是集成异构语言运行时的媒介，任何给定虚拟机的单一主机语言都无法替代它们。否则（比如说，使用SBCL或任何其他本地Lisp），您必须专门处理每个语言对的FFI和编组。NET也没那么糟糕-它也可以处理JVM（请参阅IKVM）。Lisp非常适合开发编译器，而JVM JIT确实是一个编译器。所有的事情，从简单的带模式匹配的“nano pass”到实现SSA转换，寄存器调度和指令选择都是非常好和干净的，如果在Lisp中实现的话（或者更好，在嵌入Lisp的DSL之上）。但是，当然，这个编译器不应该针对Lisp本身。非常感谢，事实上，对于垃圾收集器来说，像C这样的语言有些不合作。我的需求针对的是为什么除了提到的小而过时的项目外，开发工作如此之少的原因。我认为LLVM对于这样一个基于cou的Lisp语言环境来说是一个非常有趣的平台