比较 Common Lisp 和 Gambit 的库访问和对象系统
我对 Gambit Scheme 非常感兴趣，特别是它支持的广泛平台，以及它在需要时将 C 代码直接放入您的 Scheme 源代码的能力。也就是说，它是一个方案，与 Common Lisp 相比，它的“包含的内容”更少。有些人喜欢从头开始编写很多东西（又名大力刮牦牛毛），但我不喜欢！
这让我想到了两个问题，针对同时使用过 Gambit 和某种 Common Lisp 的人：
1）哪个能够更好地访问库？ Scheme 的库比 Common Lisp 少。然而，Gambit Scheme 可以更顺畅地访问 C/C++ 代码和 C/C++ 代码。库，其数量远远超过 Common Lisp 的库。在您看来，Gambit 的 FFI 的流畅性是否比它缺乏原生库更重要？
2）Scheme 的对象系统（例如 TinyCLOS、Meroon）与 Common Lisp 的 CLOS 相比如何？如果您发现它们缺少，您最怀念哪些功能？最后，Lisp/Scheme 中的对象系统到底有多重要？我听说整个基于 lisp 的公司（例如 ITA Software）完全放弃了 CLOS。 Lisp/Scheme 中的对象真的那么可选吗？我确实担心如果 Gambit 没有好的对象系统，我可能会错过它们（我的编程背景是纯粹面向对象的）。
感谢您帮助一位有抱负的 C++/Python 转换者，
-- Matt
PS：某人拥有超过 1500 个代表，您能创建一个“gambit”标签吗？ :) 谢谢乔纳斯！
I'm pretty intrigued by Gambit Scheme, in particular by its wide range of supported platforms, and its ability to put C code right in your Scheme source when needed. That said, it is a Scheme, which has fewer "batteries included" as compared to Common Lisp. Some people like coding lots of things from scratch, (a.k.a. vigorous yak-shaving) but not me!
This brings me to my two questions, geared to people who have used both Gambit and some flavor of Common Lisp:
1) Which effectively has better access to libraries? Scheme has fewer libraries than Common Lisp. However, Gambit Scheme has smoother access to C/C++ code & libraries, which far outnumber Common Lisp's libraries. In your opinion, does the smoothness of Gambit's FFI outweigh its lack of native libraries?
2) How do Scheme's object systems (e.g. TinyCLOS, Meroon) compare to Common Lisp's CLOS? If you found them lacking, what feature(s) did you miss most? Finally, how important is an object system in Lisp/Scheme in the first place? I have heard of entire lisp-based companies (e.g. ITA Software) forgoing CLOS altogether. Are objects really that optional in Lisp/Scheme? I do fear that if Gambit has no good object system, I may miss them (my programming background is purely object-oriented).
Thanks for helping an aspiring convert from C++/Python,
-- Matt
PS: Someone with more than 1500 rep, could you please create a "gambit" tag? :) Thanks Jonas!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当然，Scheme 作为一个整体在定义的标准中拥有较少的库，但任何给定的Scheme 实现通常都建立在该标准的基础上，以包含更多“包含电池”类型的功能。
例如，Gambit 使用 Snow 软件包系统，它可以让您访问多个支持库。
其他方案的表现甚至更好，可以访问更多（或更好）的支持库。 Racket（带有 PlaneT）和 Chicken（带有 鸡蛋）立即浮现在脑海中。
也就是说，Common Lisp 也相当丰富，并且只需简单的 asdf 安装即可获得大量有趣且有用的库。
至于Scheme对象系统，我个人倾向于支持ChickenScheme并且已经开始支持coops< /a>.也就是说，TinyCLOS 绝对没有任何问题。两者都可以很好地发挥作用，并且不会真正发现缺少什么。尽管最后一句话可能更多地与我在编写Scheme时不倾向于依赖大量面向对象主义这一事实有关。根据我的经验，当我想编写“协议”时，这两个系统都会浮出水面，然后有一种专门研究协议的方法（如果有意义的话）。
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.
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 在这方面应该没有什么不同。
1) I haven't used Gambit Scheme, so I cannot really tell how smooth the C/C++ integration is. But all Common Lisps I have used have fully functional C FFI:s. So the availability of C libraries is the same. It takes some work to integrate, but I assume this is the case with Gambit Scheme as well. After all, Lisp and C are different languages..? But maybe you have a different experience, I would like to learn more in that case.
You may be interested in Quicklisp, a really good new Common Lisp project - it makes it very easy to install a lot of quality libraries.
2) C++ and Python are designed to use OOP and classes as the typical means of encapsulating and structuring data. CLOS does not have this ambition at all. Instead, it provides generic functions that can be specialized for certain types of arguments - not necessarily classes. Essentially this enables OOP, but in Common Lisp, OOP is a convenient feature rather than something fundamental for getting things done.
I think CLOS is a lot more well-designed and flexible than the C++ object model - TinyCLOS should be no different in that aspect.