比较Common Lisp和Gambit以及它们的库访问和对象系统

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软件公司)完全放弃了CLOS.对象在Lisp/Scheme中是否真的可选？我担心如果Gambit没有好的对象系统,我可能会想念它们(我的编程背景纯粹是面向对象的).

感谢您帮助C++/Python进行有抱负的转换,

- 马特

PS:有超过1500名代表的人,请你创建一个"开局"标签？:) 谢谢乔纳斯!

Answer 1

Sure Scheme作为一个整体在定义的标准中具有更少的库,但是任何给定的Scheme实现通常建立在该标准上以包括更多"包含电池"类型的功能.

例如,Gambit使用Snow软件包系统,可以访问多个支持库.

其他方案甚至更好,可以访问更多(或更好)的支持库.立即想到球拍(带有PlaneT)和鸡(带有鸡蛋).

也就是说,Common Lisp也非常丰富,而且大量有趣且有用的库都是简单的asdf-install.

至于Scheme对象系统,我个人倾向于偏爱鸡计划,并采取了偏爱合作.也就是说,TinyCLOS绝对没有错.两者都可以很好地服务,并没有真正找到任何缺乏的东西.虽然最后一个语句可能与我在编写Scheme时不倾向于依赖很多面向对象的事实有关.当我想编写"协议"然后有一种专门研究协议的方法时,我的经验中的两个系统都会浮出水面,如果这有意义的话.

Answer 2

1）我没有使用过GambitScheme，所以我无法真正判断C/C++集成有多顺利。但我使用过的所有 Common Lisp 都具有功能齐全的 C FFI:s。所以 C 库的可用性是相同的。集成需要一些工作，但我认为 Gambit 方案也是如此。毕竟，Lisp 和 C 是不同的语言..？但也许你有不同的经历，我想在这种情况下了解更多。

您可能对Quicklisp感兴趣，这是一个非常好的新 Common Lisp 项目 - 它使安装大量优质库变得非常容易。

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

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