scheme - 方案编程和Common Lisp编程的比较

我和许多人一样，对向导计划中介绍给我的Scheme进行了Lisp编程工作。从那以后，我对Common Lisp做了一些工作，并且很长一段时间我转到了Haskell（我很喜欢），但是现在我又回到了Lisp，因为它似乎更宽容了一个情妇。

我现在再次面临Common Lisp和Scheme之间的选择，我希望在选择方面有所帮助。我的问题不是“哪个更好？”或“我应该选择哪个？”而是“ Lisp Lisp可以为我提供Scheme不能提供的服务？”。一旦掌握了这些信息，我将运用自己的价值判断做出决定。

我听说Common Lisp的功能更广泛，而Scheme更为保守和严厉，但是在我的临时使用中，我无法找到Scheme中也没有的Common Lisp的任何功能。根据我的喜好，更多功能不一定是一件好事（例如，我更喜欢C而不是C ++，恰恰是因为我觉得C ++过于膨胀），但是一个可靠的实用功能可能足以使我喜欢大语言而不是小语言。 Common Lisp具有哪些功能，但是Scheme没有？再次，在我的临时使用中，我找不到任何功能！

以下是我某些特定的知识，它们在Scheme和Common Lisp之间是不同的：

普通Lisp是“ Lisp-2”；也就是说，它有一个单独的变量命名空间，而Scheme没有。总的来说，我认为我更喜欢Scheme的统一名称空间，而不是Common Lisp的split方法。（作为次要切线，CL标准中区分变量和函数的含义是什么？不是全部都是函数吗？）
方案的(define)格式与CL的(defun)宏非常不同； (define)可用于在范围内定义局部函数，然后在该范围内的任何其他地方使用该函数，直到它超出范围为止。 (defun)始终在全局级别运行，与Scheme的(define!)类似。我发现模仿CL中Scheme的(define)的行为的唯一方法是使用flet，它会很快变得非常混乱。
CL的宏与Scheme的不同，不卫生。显然，如果您知道自己在做什么，就可以利用此功能，但是我不知道我在做什么。

请注意，通过“方案”，我不是指的是球拍。我一直使用的Scheme的主要版本是Guile和MIT Scheme。球拍似乎与其他计划有足够的区别，我现在不希望使用它。

我想知道的另一件事与Common Lisp和Elisp之间的区别有关。我听说它们比Scheme中的任何一个都更相似，并且几乎相同。有什么区别？

TL； DR： 也许R7RS-large可以提供帮助，但是我们今天所知道的Scheme并不适合所有人。普通Lisp更具可扩展性

我是一个大风扇方案，并伤心地说但没有报告有任何标准化的方式做任何FFI。如果您需要获得某些尚未间接支持的库或操作系统功能的支持，则无法通过任何当前的Scheme标准获得该功能。

一个很好的例子是一个简单的数据库驱动程序。 MySQL和Postgres在许多语言中都是非常标准的，如果要提供后端服务，则必须这样做。在Scheme中，您没有标准的方法。有些实现实际上提供了一些方法，但是您会陷入困境，而不再是Scheme。如果幸运的话，某些实现可能会实现SRFI-106 basic socket interface以便可以制作一个纯粹的Scheme驱动程序，但这并不是最佳选择。

Scheme的后代，即球拍#lang racket，是包含一些与R5RS兼容的电池，可以与Common Lisp进行比较，但不是Scheme。它具有数据库驱动程序甚至FFI，因此可以在功能上与Common Lisp竞争，但这是一种实现语言。由于不是方案，我想我的答案中不应提及它。

方案编程和Common Lisp编程的比较

1 个答案: