这是因为Clojure受JVM限制，所以此代码无法评估？

-1

代码在Clojure中包含类似'(1+2)的内容将导致java.lang.RuntimeException，这会留下错误消息“不匹配的分隔符：）”。这是因为Clojure受JVM限制，所以此代码无法评估？

但在任何其他口齿不清的方言我曾经使用过类似的Emacs Lisp或球拍，'(1+2)只会返回一个列表，其中应该行为像这样因为与特殊形式报价，列表中的任何事情不应该被评估。

所以我只是想知道是否由于JVM的限制，所以这些代码不能像其他方言那样行事？或者它是Clojure的错误？或者，在Clojure和其他lisp方言中引用的定义有所不同？

2016-08-20 Eleven

实际的错误是'NumberFormatException无效的数字：1 + 2 clojure.lang.LispReader.readNumber（LispReader.java:330）'。这是因为clojure正在尝试（和失败）读取一个数字。由于试图读取表达式的其余部分，之后出现不匹配的分隔符错误。 – dsm

我看不出如何将此行为绑定到JVM。 –

这些是分词器设置为不同语言的方式的工件。在Clojure中，如果一个令牌以一个数字开始，它将被消耗，直到下一个读者宏字符（包括括号在内），空格或文件结尾（空格包括逗号）。消耗的内容必须是一个有效的数字，包括整数，浮点数和有理数。所以当你给'(1+2)提供给阅读器时，它将消耗1+2作为一个标记，然后无法匹配整数，浮点数或有理数的模式。之后，读者尝试恢复，这会重置其状态。在这种状态下，)是无与伦比的。

尝试输入'(1 + 2)而不是（请注意+左右的空格），您将会看到您所期望的。

来源

2016-08-20 06:09:42

感谢您的回答。因此，Clojure总是会尝试解析每个元素，并首先将它们转换为一些Java对象（整数，字符串等），即使当列表被引用时，而不是将它们视为符号？ – Eleven

*每个*语言处理器必须首先解析其输入。您如何期望Clojure或任何其他Lisp理解您没有首先解析表达式的引用列表？要指出的第二件事，**未评估**并不意味着**未分析**。 Lisp中的单词评估具有确切的意义 - 它在头部位置调用函数，宏或特殊形式。这当然可以通过一个“引用”来避免 - 在Clojure中，就像任何Lisp一样。 Clojure是一个Lisp，比elisp更接近Scheme。你在错误的地方寻找差异。 –

我*想*它大致相当于说：在clojure中，引用形式内的内容是* read *，但不是*评估* ---并且读者不知道如何处理'1 + 2' - - 它不是一个有效的符号（符号不能以数字字符开头），关键字，数字等。 –

这是因为Clojure受JVM限制，所以此代码无法评估？

回答

相关问题