6

我对 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”标签吗？:) 谢谢乔纳斯！

4

2 回答 2

5

Sure Scheme as a whole has fewer libraries in the defined standard, but any given Scheme implementation usually builds on that standard to include more "batteries included" type of functions.

Gambit, for example, uses the Snow package system which will give you access to several support libraries.

Other Schemes fare even better, having access to more (or better) support libraries. Both Racket (with PlaneT) and Chicken (with eggs) immediately come to mind.

That said, the Common Lisp is quite rich also and a large number of interesting and useful libraries are a simple asdf-install away.

As for Scheme object systems, I personally tend to favor Chicken Scheme and have taken to favoring coops. That said, there's absolutely nothing wrong with TinyCLOS. Either would serve well and don't really find anything to be lacking. Though that last statement might have more to do with the fact that I don't tend to rely on a lot of object oriented-isms when writing Scheme. Both systems in my experience tend to surface when I want to write "protocols" and then have a way of specializing on the protocol, if that makes sense.

于 2011-01-03T23:14:58.737 回答
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 在这方面应该没有什么不同。

于 2011-01-03T21:26:13.317 回答