https://github.com/program-in-chinese/overview/issues/11#issuecomment-570023265
Kotlin是理论和实践的完美结合，所以，用Kotlin吧！ 😂

#dalao https://github.com/anqurvanillapy

真假(boolean)、数值(Number)、
字符(byte)、短数(short)、数、长数(long)、
短浮数(float)、浮数(double)、
字(char)、文(String)、
组(array)、值(Object)、
函数(Function)、
可抛(Throwable)
Bool Num Char Str Ary Object Function Error

封装、抽象、继承、多态(子类型多态、参数化多态、特殊多态(函数重载、类型转换多态))

https://github.com/program-in-chinese/overview/issues/11#issuecomment-570032696 #Low #China
https://wenku.baidu.com/view/d4424def4afe04a1b071de17.html

这篇论文真是废话满篇。对 踌躇 和 踌躇志满 的区分要么然认为是『第一级解析』上要么然认为是『第二级解析』，这种东西还能先分成 踌躇、志满，应该是一次弄完的。

这人大概是自然语言学者，不是编程学者，尽说些没用的。全篇我没见他贴半点有效的代码，尽是写 natural language 的 statement，还都是那种无论对计算机还是对编程都表义不明的。

全篇什么作用域、指针、冯·诺伊曼、文法推导处理过程，全都是拼接一样，我肯定这人是第一次写这种论文，要不然他不至于连一点整理都不会做，是啊，说的都对，有什么用？能拿来编程吗？做不做工程是不一样的。

想来，冯·诺依曼体系很早就在编程语言中被突破了。

到现在，只有贵得不行的 Oxygen XML Editor Edition 才能像话地为拥有不同内部结构与格式的 XML 文件撰写内容。gnu gettext 之类翻译工具不至于没法用，但它们的输出展示结果不可能能够应对，或者拥有 XML 的层次结构。

与此同时，借助数据格式特性，分层分组的 XML 文件早已很常见了，JSON 之类也可能在路上。可能需要进化的是各种翻译工具。

#dalao https://inner.xieyuheng.now.sh/contents

杀人者死，伤人及盗抵罪。

—

引记法 绝句.符号 「之」

事 严明执法(此人：人) 为
  若此人之曾杀人，杀(此人)。
  若你此人或之曾伤人或之曾盗窃，此人去抵(此人的罪)。

fun judge(one: Person) {
  if (one.killedSomeone) kill(one)
  if (one.didHurtSomeone || one.didThief) one.payFor(one.sin)
}

还好，就这个程序来说不必劳烦 判 语法了。

然后我觉得，反正绝句里「你」就有作用域混入的效果，不如给一般的模式也加上……

事 严明执法(此人：人) 为
  若此人之曾杀人，杀(此人)。
  若你此人或之曾伤人或之曾盗窃，你去抵(你的罪)。

……但总感觉有点怪怪的？

你此人或之曾伤人或之曾盗窃

这是一个表达式
但那样就要引入「若(你……)」这种特化的语法（不然拿不到作用域里「你」的意思？好像也有方法）了，我还是不确定……
—
我们知道「你」的「且/或」形式目前仅能应用于需要「真假」值的地方。
这事实上就是不得不对所有需要真假值的语言结构，「若」「重复若」添加特化的『形式』。

比如「若你」「重复若你」，当然「对…里的你……」其实是已经有的语言结构……

虽然这相对较为对称，但我还是要调整下心态……

尽管好像是那样的，但「对…里的你……」和「若你(且/或)……」的用法是不一样的，「对」里的可省略「你」这个主语，另一个不行…… 反正「你」已经是苛性构词了，就是作用域结构上的差异，具体是否加入以后再考量吧。

不过「对…里的你……」中引用可不带主语「你」

这实际上就是给语言引入了一个不一致的特性，之前支持「若你」是为了一致、现在不想支持也是为了一致。
为了更类似于自然语言上应该是必须支持的（而且对于自然语言这样的表达有准确性），这种写法我预计也会比较常用，也不是很麻烦。

但就语言定义上来看，它是不太容易理解的，不是很清楚是否该加。 #PL #jueju

对了，为什么不把这个 不过「对…里的你……」中引用可不带主语「你」 的特化处理给去掉呢？反正去掉也不会使得代码更难看啊！这样不就一致了吗？「你」就像是对表达式的一个标签，不存在作用域处理上一致性的问题。

……可那样 对…里的你 和 对…里的…… 还有什么区别啊？？？那就只能删掉这个用法了……
唉

其实 对…里的你…… 也是有语言一致性的，因为「你」本身就代表作用域混合。

可是我们不能让

“……”

若此人之曾杀人，杀(此人)。


  若你此人或之曾伤人或之曾盗窃，此人去抵(“此人的”罪)。 

这种代码通过啊？！

这绝句越设计越像自然语言了，可这……真的没问题么；我感觉第二人称文法是个潘多拉盒子，支持了指不定会怎么样。

这么说吧，其实这个选择也就是绝句是走「倾向自然语言」还是「倾向更规范的编程语言」的区别，也就是设计的分岔路。

不错，其实绝句完全可以不多作考量就立刻以我上面那个折衷法立刻准备加入正式设计的，可我觉得还是有点问题需要讲明白。
这个语法，它不像 尝试…成…… 那样，它是无可替代的，绝句里没有任何其他方法可以直接代替它作为表达式的位置，因为它一是在汉语言里属于对语言表达有极其特殊地位的构词而不应该在任何情况下作为名字的起始使用，二是它可以使得 a > 1 && a in xs 这种表达式更好描述，绝句里也有类似的并例（例如「」叫括号的中缀简记）。

就绝句未来而言，我觉得我的看法和 Matz 是一样的，不能把语言设计得太『简单』或过分数学、过分强调语言理论准确性，我不希望绝句成为『中文编程』领域的Scala（的确我也没那个水平），但是我觉得『自然』也是有限度的，不能没有章法。

第二人称文法其实本身就是一种会扰乱语言表达规范性的特性，支持它可以让语言、对程序的描述更直白、更自然，有很大的积极作用，唯一的问题是——它是对作用域定义的扩充，利用它可以写出莫名其妙的程序，而绝句不可能检查这种情况，因为首先它们本该符合语法，其次这种检查是吹毛求疵的行为。

下面有相似的三个例子。

对此办公室里的你，
  若年龄不大30且头衔是总监，说(你的名字)。

这是正常情况，也就是我觉得有必要加入此语法的理由。——况且这的确是很常见的一种模式（当然 Kotlin 也可以用 E.() -> Unit 模拟，可为了一致性最好还是加上，而且那样就没有第二人称「作用域混合」了）

上面的『名字』『年龄』，很自然就能知道是指『存于办公室的某人』。（这里不提里面有很多行代码的情况，绝句里还能写很复杂很多行纯属编程方法有问题）

对里的你(办公室) { if (年龄<=30 && 头衔==总监) println(this.名字) /*注意这里就和第一人称的this混淆了，没法直接引用外层的this*/ }

Kotlin 的写法类似以上

对此办公室里的你，
  若甲君的名字[0..1]是名字，说("啊，${名字}你和${甲君}是一家的啊？")。 “开个玩笑”

这种情况，就没那么容易想出『名字』是指谁的名字了（甚至会与名字作为一类事物的情况发生混淆），或者说，对于以上代码可以调整「是」的语序修改，可我之前说过，严格的好语言不应该可以写出烂代码，那往往是设计思虑不够深刻导致的。

对零食区里的你，
  取色笔去取色(外封)令为，说("$它 $口感")。

这里就更明显了，我们引入了一个块，谁能一眼看出『口感』是指『存于零食区的某物』的口感？？？

……我觉得暂时还是支持吧。毕竟这个语法虽然让绝句不是那么『严格』了，在中文表达里它也是有价值的，而上面举出的问题程序其实本身以中文的视角看都是语素残缺、逻辑错误的，或许能够以中文的思路看绝句程序会有利于代码质量的提升。

我觉得，既然都无法确定的话…… 那还是用 plan C 好了，去掉 对……我 的特殊对待，这样虽然看起来有点弱智但不至于弄乱整门语言。
对应地，「你」的『文言式作用域混合』也就是『你(言)……』的情况…… 还是保留吧。

对此办公室里的你，
若你的年龄不大30且你的头衔是总监，说(你的名字)。

事 严正执法(此人：人) 为 “用起来不自然但这只是例子”
若此人之曾杀人，杀(此人)。
若你此人或之曾伤人或之曾盗窃，你去抵(你的罪)。

这样看起来一致性就好多了，「你」后面跟的都是「你的」「你去」。

啊，不是，我这里指的翻译是计算机科学程序表示和转化领域的『翻译』，也就是编译器进行的『翻译』，不是自然语言的那个『翻译』……

艹，好像不能完全避免 bug，我改了一次后出了无数个拼写错误，而且还有两个 nullibility 的问题和一个泛型参数弄错