标签：struct 实现 编程 语言 版本 cto 数据解析 临时 出现
今天是2019年2月6日。(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里。目前的计划是，为表达式对象封装上一层，把宏附在这一层上，则模型就变成了“宏式的子项也是宏式”，重写宏式的求值。不过此刻这个计划就已经停下了。本打算定义个常量，写个递归，算了吧。
（于地球）
标签：struct 实现 编程 语言 版本 cto 数据解析 临时 出现
原文地址：http://blog.51cto.com/13535617/2348830
