今天是2019年2月6日。
一年半以前,我開始接觸到編程,不久後,出於對lisp的不滿,我開始設計一種新的編程語言,並臨時命名爲「Error」(閱讀提醒:我至今未能肯定規則,但有基於某時的規則的實現)——我是個很沒有起名天賦的人。關於error我也曾在這裏(51cto)發表了blog(/13535617/2061128),如今看來很有幾分感慨。error是我對於編程體系的幻想,它彷佛非得打破「語言」這個東西不可——但這也不是error獨有的,語言都不純粹地是語言。好比……c語言有預處理這個概念,python沒有。
error像lisp同樣但願代碼也是數據,但又但願嚴格劃分兩者。因而引入了一個新的概念「error對象標記方法」,能夠說它是個lisp一點的json。好比python
(len: ["orange" "lemon" "ice"])git
經過冒號來區分表達式和表(我使用「元組」、「列表」、「元組調用」、「列表調用」這些稱呼)。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裏。目前的計劃是,爲表達式對象封裝上一層,把宏附在這一層上,則模型就變成了「宏式的子項也是宏式」,重寫宏式的求值。不過此刻這個計劃就已經停下了。本打算定義個常量,寫個遞歸,算了吧。
(於地球)github