今天是2019年2月6日。
一年半之前，我開始接觸到編程，不久後，出於對lisp的不滿，我開始設計一種新的編程語言，並臨時命名爲“Error”（閱讀提醒：我至今未能確定規則，但有基於某時的規則的實現）——我是個很沒有起名天賦的人。關於error我也曾在這裏（51cto）發表了blog（/13535617/2061128），現在看來頗有幾分感慨。error是我對於編程體系的幻想，它似乎非得打破“語言”這個東西不可——但這也不是error獨有的，語言都不純粹地是語言。比如……c語言有預處理這個概念，python沒有。
error像lisp一樣希望代碼也是數據，但又希望嚴格劃分二者。於是引入了一個新的概念“error對象標記方法”，可以說它是個lisp一點的json。比如
(len: ["orange" "lemon" "ice"])
通過冒號來區分表達式和表（我使用“元組”、“列表”、“元組調用”、“列表調用”這些稱呼）。error的語言部分就是用這種方法表示的，所以它可以被當做數據解析。而在運行的時候，調用式是無法被解析出調用者和參數的，預處理則可以。給error加入預處理的原因是，我覺得“在語言中指定哪些是運行前做”相當正義，這是不久之前的事。假如要在代碼中設定一些需要運算得到的常數，沒有人希望每次運行時都計算吧？（python便如此。）可以使用error語言的預處理，也可以自己實現預處理。隨着對error的思考和時間推移，我漸漸意識到我好像不是在思考語言——這些根本無所謂用什麼符號來表示，只要這些符號能夠確定出——一個error語法結構，類似抽象語法樹的東西。我發現我從來不知道error是什麼，它只不過是一堆願望的集合——就像人所說的“人工智能”一樣。
但能明確到“語法結構”已經不錯了。文本首先要變爲error語法結構（不管以何種文本，何種對應的處理方式），而預處理也是在語法結構上進行，而非文本上。其實完全可以用“修改語法樹”的說法，但我不喜歡“語法樹”這個詞，因爲比起普通意義的樹，它多了很多限定的東西，和struct倒更像些。let（類比lisp的let，python的帶dict的eval）和getmethod（類比python的getattr、點操作符）就可以被看成預處理，或者說（靜態的）宏。但它們似乎也可以部分地以函數而非宏的形式存在，然後導致爲語言添加很多其他東西——也是我在想到可以用預處理之前花了很多精力去糾結的東西。你可以輕鬆地寫下(let: [(x 1)(y 2)] (+: x x))、((getmethod: move): car)、(lambda: [a b] (+: a b))這種表達式，但你會想，這真的是函數嗎？（error默認所有參數惰性求值，故僅需延遲求參的if，for等都視作普通函數。）前者改變了“環境”（而環境是什麼都很難說！），後二者則沒有類型推導可言（即使error並不推導類型，它們依舊顯得特殊）——“甚至把表達式當做運行時對象都已經很特殊”——我對error的期望不停地在改變，譬如一開始error不自定義對象也不使用getmethod。而自定義對象能否和內置對象統一起來，也是我一直不得其解的問題。
error語言困擾了我很久。其實error曾經並不被我放在心上，我思考的東西是人工智能和心理學。在一度失利下，error愈發牽引着我的注意力，就像上學時的聽課，總能給我做其他事的動力。而又隨着厭倦法則的持續作用，error對我也不那麼吸引了（也正是我一開始所希望的）。現在這個計劃——應當陷入沉睡了。而我所需要做的是，把目前已有的東西交代給虛無。
在不考慮預處理的情況下，函數對象是要在運行時創建的。但我們似乎也“希望”能在運行前創建出函數，和可能在運行時被閉包的函數，等等；error對象標記方法中，原則上連整數，小數都不允許出現，因爲只有字符串是無歧義的，要表示1只能用(int: "1")的形式，而int爲宏，除了解決複數四元數的擴展紛爭，也算是致敬tcl語言；一個字符只要不是空白符和已佔用的符號（雙引號，冒號，圓括號方括號）就可以作爲標識符成分；error的一切都是對象，它如何與操作系統交互，如何讀寫文件和輸出，一直沒有思考，僅僅把它用在python的交互模式下了。原則上它應該也在函數式的系統中運行，但這些又意味着什麼，我沒有思考。
目前有一個簡單的版本位於github的lamdba/error，此前有過棧實現來調用函數（甚至一度爲了方便以後轉化爲彙編，沒有使用類），但再讀起來很不方便，就放棄了，那些代碼始終潛藏在lamdba/error_s1的git裏。目前的計劃是，爲表達式對象封裝上一層，把宏附在這一層上，則模型就變成了“宏式的子項也是宏式”，重寫宏式的求值。不過此刻這個計劃就已經停下了。本打算定義個常量，寫個遞歸，算了吧。
（於地球）