這是因爲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限制，所以此代碼無法評估？

回答

相關問題