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

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

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

但就语言定义上来看，它是不太容易理解的，不是很清楚是否该加。 #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 的问题和一个泛型参数弄错

不过，出错以后更好改是真的，因为总感觉自己只不过是在写字一样所以没有心理压力

https://github.com/duangsuse-valid-projects/Share/commit/d6f91d73fc59cd415c868f8ca1362d6a0426713a
像写一篇文章一样编程的好处很明显，就是思路是清晰的（虽然我这个层次也做不到一遍不错地完成，如 nullability 和 upper bound 上，但思路很明确）
尽管还是需要改很长时间，但不会觉得自己很苦逼，好像只是在写篇博文一样，尽管没有 IDE 的帮助，这种感觉很有趣。

#PLT #CS #dev #Kotlin

https://github.com/neilgall/KotlinKanren/

Kotlin 的 MiniKanren 也有了，可是 是从 Swift port 过去的，而且实现的易读性、设计的可扩展性都不够，我打算写基础的 "Literate Kotlin" 辅助 JS 脚本（临时），然后实现一个 Kotlin 的 MiniKanren(其实是 microKanren……)。

我来谈谈 Literate Kotlin 的脚本应该怎么写。 #JavaScript

这个脚本，就是要允许我们在文章里嵌入 Kotlin 代码和依赖代码的示例，
然后每个相对独立且可以作为 Kotlin File 编译的部分完成后，显式一个按钮以归总一个部分的代码，并允许在 Kotlin Playground 执行它。
（感谢 JetBrains 特地包装的这个编辑器，使用一点也不困难，尽可能减少了我在无意义事情上花费的时间和痛苦）
至于 Kotlin Playground 的部分他们提供了很简单的 API： playground('code') // enable on all <code>
所以我们只负责拼合代码。

每个独立部分 <template literateBegin /> 起始、 <template literateEnd /> 结束，其中可以有许多不可嵌套的 <template exampleBegin /> 和 <template exampleEnd />。

之前我是直接写 imperative 表述式来 filter 出 language-kotlin 的 <code>，后来我抽提了 nextSiblings 和 takeWhile，就不那么死板了：

function *nextSiblings(e) { for (let c = e; c!=null; c=c.nextSibling) yield c; }
function *takeWhile(p, xs) { for (let x of xs) if (p(x)) { yield x; } else break; }

function filterCode(begin_e, p = e => e.classList.contains("language-kotlin")) {
let neighbors = nextSiblings(begin_e);
let section = takeWhile(notSectionEnd, neighbors);
return [...section].filter(p).map(e => e.innerText).join("");
}

这个 filterCode 函数直接给它起始 <template literateBegin> Element 就可以了
然后在页面渲染完成后，可以添加钩子逻辑，来在 <template literateEnd> 后插入一个 button 来显式此部分的代码 <code>。

但关键问题是，如何区分 literate 和 example，这个问题也很好解决，利用『模式(pattern)』来表达：

Sections = {Section}
Section = <template literateBegin/> (anyElement|Example)*? <template literateEnd/>
Example = <template exampleBegin/> anyElement*? <template exampleEnd/>

这么做是为了 literate|example 模式数据提取实现不止可用于 Kotlin 代码，之后我们从 anyElement 中 filter 出需要的 Kotlin code。
解析的结果是 literate element 的集合，以及 example element 的集合。

为了能够写这样的代码，就不得不编写这个辅助类（如，takeWhile 会在第一个不符合 p 处停下，这里可能是 literateEnd或exampleBegin可我们必须区别处理，不得不保证对末项访问可能性）

思维江化，无法和曾经费了很长时间想的模型对应起来。