今天是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