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

艹，好像不能完全避免 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可我们必须区别处理，不得不保证对末项访问可能性）

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

想到了，原来我让 next() 去回 lastItem，然后 [1, 2, 3] 第一次 lastItem=1；next 流就是 [1,2,3]，比之前 constructor: lastItem=gen.next() 多 next 一次是为了 next 出所有项目包括 peek 的。
而现在的 peek 实际上更加直白，就是让 iterator 把那个直接补回去，不必再用 tailConsumed 那一套 peek+yield in next 修补方案了，也没有 tail 需要特殊处理的问题。

ES6 的版本

这样的代码可以解析如上模式