比较Common Lisp和Gambit在库访问和对象系统方面的差异

Question

比较Common Lisp和Gambit在库访问和对象系统方面的差异

6

我对Gambit Scheme非常感兴趣，特别是它支持的广泛平台和在需要时将C代码直接放入Scheme源代码中的能力。尽管如此，与Common Lisp相比，它是一种Scheme，其“内置电池”较少。有些人喜欢从头开始编写很多东西（也就是繁琐的工作），但我不喜欢！

这引出了我的两个问题，针对那些使用过Gambit和某种风味的Common Lisp的人：

1）哪个有效地访问库？Scheme的库比Common Lisp少。然而，Gambit Scheme可以更顺畅地访问C / C ++代码和库，这远远超过了Common Lisp的库。在您看来，Gambit的FFI的顺畅性是否超过了其本地库的缺乏？

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

感谢帮助我从C ++ / Python转变的人，

- Matt

PS：有超过1500 rep的人，您能创建一个“gambit”标签吗？ :) 谢谢Jonas！

- SuperElectric

2个回答

2

1) 我没有使用过Gambit Scheme，所以我无法真正告诉你C/C++集成有多顺畅。但是我使用过的所有通用Lisp都具有完全功能的C FFI:s。因此，可用的C库相同。需要一些工作来进行集成，但我认为这也适用于Gambit Scheme。毕竟，Lisp和C是不同的语言..？但也许你有不同的经验，在这种情况下我想学习更多。

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

2) C++和Python旨在使用OOP和类作为封装和结构化数据的典型手段。 CLOS根本没有这个野心。相反，它提供了可以针对某些类型的参数进行特殊化的通用函数 - 不一定是类。基本上，这使OOP成为可能，但在通用Lisp中，OOP是一个方便的功能，而不是完成任务所必需的基本要素。

我认为CLOS比C++对象模型设计得更好、更灵活 - TinyCLOS在这方面应该也不例外。

- Johan Kotlinski

仅仅拥有FFI的问题在于，它强制你从Lisp中包装每个函数。即使借助SWIG的帮助，这也很快变成了一项繁琐的任务。Gambit具有优势，允许您将一块C（和C++！）代码直接插入到Scheme源代码中。换句话说，您只需要为需要传递到该块中的任何数据编写接口代码，而不是为该块中的每个函数编写接口代码。这很棒，因为您经常需要一起使用一堆C/C++函数来产生您感兴趣的结果，并且只关心包装结果。 - SuperElectric

@SuperElectric：但是你总是可以将那个 C（或 C++）代码块放入一个 C 函数中，然后通过 FFI 访问这个函数。 - user2545918

@MiklósHomolya 确实如此，但这是方便的问题。从我使用Lush的经验来看，我可以说，在Lisp函数体中只需放置一些C代码，并使其能够访问范围内的任何Lisp变量，这是一个巨大的生产力优势。 - SuperElectric

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Shaun · Accepted Answer

虽然整体而言，Scheme标准库的数量较少，但任何一个Scheme实现通常会基于该标准构建，包括更多“内置电池”类型的函数。

例如，Gambit使用Snow软件包系统，这将使您可以访问多个支持库。

其他Schemes表现得更好，可以访问更多（或更好）的支持库。 Racket（使用PlaneT）和Chicken（使用eggs）立即就能想到。

话虽如此，Common Lisp也非常丰富，大量有趣且有用的库只需要简单的asdf-install即可获得。

关于Scheme对象系统，我个人倾向于使用Chicken Scheme并且喜欢使用coops。话虽如此，TinyCLOS也没有任何问题。两者都很好用，我没有发现任何缺点。不过，这最后一句可能更多地与我在编写Scheme时不太依赖许多面向对象的特性有关。在我的经验中，这两个系统往往会在我想要编写“协议”并且需要一种在协议上进行特化的方式时浮现出来，如果这有意义的话。