比较 Common Lisp 和 Gambit w.r.t 的库访问和对象系统

Question

我对 Gambit Scheme 非常感兴趣，尤其是它支持的广泛平台，以及它能够在需要时将 C 代码直接放入您的 Scheme 源代码中。也就是说，它是一个方案，与 Common Lisp 相比，它的“包含的电池”更少。有些人喜欢从头开始编写很多东西（也就是大力刮牦牛），但我不喜欢！

这让我想到了我的两个问题，面向同时使用 Gambit 和某种 Common Lisp 风格的人：

1) 哪个有效地更好地访问图书馆？ Scheme 的库比 Common Lisp 少。然而，Gambit Scheme 可以更顺畅地访问 C/C++ 代码和库，这远远超过 Common Lisp 的库。在您看来，Gambit 的 FFI 的流畅性是否超过了它缺乏原生库？

2) Scheme 的对象系统（例如 TinyCLOS、Meroon）与 Common Lisp 的 CLOS 相比如何？如果您发现它们缺少，您最想念哪些功能？最后，首先，Lisp/Scheme 中的对象系统有多重要？我听说整个基于 lisp 的公司（例如 ITA Software）完全放弃了 CLOS。 Lisp/Scheme 中的对象真的那么可选吗？我确实担心如果 Gambit 没有好的对象系统，我可能会错过它们（我的编程背景是纯面向对象的）。

感谢您帮助有抱负的 C++/Python 转换，

-- 马特

PS: 有超过 1500 个代表的人，你能创建一个“gambit”标签吗？ :) 谢谢乔纳斯！

Answer 1

当然，Scheme 作为一个整体在定义的标准中具有较少的库，但任何给定的 Scheme 实现通常都建立在该标准之上，以包含更多“包含电池”类型的功能。

例如，Gambit 使用 Snow 包系统，它可以让您访问多个支持库。

其他方案的表现更好，可以访问更多（或更好）的支持库。 Racket（PlaneT）和 Chicken（eggs）都会立刻浮现在脑海中。

也就是说，Common Lisp 也很丰富，而且大量有趣且有用的库只需 asdf-install 即可。

至于 Scheme 对象系统，我个人倾向于支持 Chicken Scheme 并且已经开始支持 coops。也就是说，TinyCLOS 绝对没有问题。两者都可以很好地发挥作用，并且不会真正发现任何不足之处。尽管最后一句话可能与我在编写 Scheme 时不倾向于依赖很多面向对象的事实有关。根据我的经验，当我想编写“协议”时，这两个系统都倾向于浮出水面，然后有一种专门研究协议的方法，如果这有意义的话。

Answer 2

1) 我没有使用 Gambit Scheme，所以我无法真正说出 C/C++ 集成的流畅程度。但是我用过的所有 Common Lisps 都有功能齐全的 C FFI:s。所以C库的可用性是一样的。集成需要一些工作，但我认为 Gambit Scheme 也是如此。毕竟，Lisp 和 C 是不同的语言..？但也许你有不同的经历，在这种情况下我想了解更多。

您可能对Quicklisp 感兴趣，这是一个非常好的新的 Common Lisp 项目 - 它可以很容易地安装许多高质量的库。

2) C++ 和 Python 旨在使用 OOP 和类作为封装和结构化数据的典型手段。 CLOS根本没有这个野心。相反，它提供了可以专门用于某些类型的参数的通用函数——不一定是类。从本质上讲，这启用了 OOP，但在 Common Lisp 中，OOP 是一个方便的功能，而不是完成工作的基础。

我认为 CLOS 比 C++ 对象模型设计得更好也更灵活——TinyCLOS 在这方面应该没有什么不同。