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

Question

我对 Gambit Scheme 非常感兴趣，尤其是它广泛的支持平台，以及它在需要时将 C 代码直接放入 Scheme 源代码的能力。也就是说，它是一个 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)和鸡(eggs)立即浮现在脑海中。

也就是说，Common Lisp 也非常丰富，大量有趣和有用的库只需简单的 asdf-install 即可。

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