弧线相对于球拍的优势

Posted 2023-02-21

【中文标题】弧线相对于球拍的优势

【英文标题】：The advantage of Arc over Racket

【发布时间】：2012-01-23 05:39:12

【问题描述】：

Arc 建立在Racket 之上。由于他们都属于 Lisp 家族，我很好奇 Arc 相对于 Racket 的优势，或者考虑到 Racket 可用，创建 Arc 的动机是什么？

【问题讨论】：

Python 是“建立在”C 之上的，那么 Python 相对于 C 的优势是什么？底层语言，除非暴露出来，否则与“顶层”的力量无关。

我怀疑有没有——scheme 是一种众所周知的、相当流行的语言，其中包含用于做事的库，而 arc 是一个创建早期网络商店的人的虚荣项目。

将 DSL 与完全独立的语言进行比较似乎有点愚蠢。例如，我不会说“LiftWeb 或 Scala”或“Seaside 或 SmallTalk”或“Sinatra 或 Ruby”。 （授权的 Lisp 形式确实可以模糊区分。）

@pst：Arc 被称为 a Lisp，因此是一种新语言，而不是 DSL。这一事实表明 PG 正在改变事物，而不仅仅是添加到 Racket 中。如果您知道这是错误的，那将是一个有用的答案，但说这个问题很愚蠢是没有帮助的。

@drysdam：如果 Python 构建在 Ruby 之上，情况会更接近并行（但仍不完美），有人问 Python 相对于 Ruby 有什么优势。如果没有暴露 Racket 的任何部分，那么这是有用的信息，并且可能是有用答案的一部分。告诉人们他们的问题很愚蠢通常不是很有用。

【参考方案1】：

从某种意义上说，编写自己的语言是一种授权：您可以选择哪些原语、哪些类型的表达式便于用该语言编写。从这个意义上说，您可以查看像 On Lisp 这样的书，并看到 Arc 的核心作者对他们希望从一种语言中获得什么样的东西有着强烈的看法。

如果我把你的问题归结为要点，听起来是这样的：人们为什么要编写特定领域的语言？

（当 Racket 中已经内置了这样的机制时，考虑 Arc 人员是否应该重新实现这么多原始设施，例如他们自己的宏和模块系统，这是一个单独的问题。但是 Arc 的作者完全在他们的范围内重新发明的权利。）

我想我对 Arc 的反对意见之一是：他们实现官方运行时的方式使得他们很难将他们所做的工作重用回普通的 Racket。从这个意义上说，这种努力只能帮助一个社区，而如果能够轻松地从 Arc 人员的工作中受益，那就太好了。

【参考方案2】：

Racket 是 Scheme 方言，而 Arc 不是。不过，它们都是 LISP 方言。 Arc 减少了括号的数量，并有一些花哨的内置语法来使常见的东西在代码大小上更短。例子：

;; scheme
(if p1 c1
    (if p2 c2
        (if p3 c3 a3)))

;; arc simplifies if
(if p1 c1
    p2 c2
    p3 c3
       a3)

;; scheme
(f1(f2(f3 a b)))

;; arc simplifies cascading calls
(f1:f2:f3 a b)

;; scheme
(lambda (x) (+ x x))

;; arc simplified one argument anonymous functions
[+ _ _ ]

;; scheme array access
(vector-ref v1 5)

;; arc simplifies array access
(v1 5)

您可以选择其中之一。我个人喜欢 Arc 语法，但不喜欢它作为解释器实现的事实。我希望他们从那时起将 Arc 实现为 Racket 模块语言，您实际上可以在 drracket 中进行开发、调试和制作可执行文件。这甚至可能允许在 Arc 中制作 Racket 库，反之亦然。

如果你想制作兼容的代码，你应该更严格地使用 R6RS/R5RS，而不是使用 Racket 默认语言或 arc，因为那时你可能拥有可以在不只是球拍上运行的代码。在球拍中，您可以选择 R5RS 或使用 #!R6RS 作为代码中的第一行来强制标准。在这两种情况下，结果都将能够在其他实现/编译器下运行。

【讨论】：

对于球拍的第一个案例，我想说一些关于 cond 的事情。 (cond (p1 c1) (p2 c2) (p3 c3) (#t c4)) 是一个更公平的比较。