<div class="literateBegin" id="input-impl"></div>
<div class="literateBegin" depend="input-impl"></div>

现在可以这么写了。我艹，原来 exampleBegin 什么的都是过度设计，section 依赖才是真理啊！ #Kotlin
还是只有 literateBegin / literateEnd，可是却可以随便写 example，而且兼容独立按 md 文件单元编译的 standalone tool，还真是蛮 effective，适合我这种菜鸡。

突然觉悟我这个其实写错了啊！它既不是 peek 也不是 lastItem/consume！
peek 的肯定是 next 啊！可是这个只有第一个的 peek 是 next，其他的都是 lastItem…… 所以说 iterator 里应该是 yield lastItem 的，然后取下一个 lastItem。

而我要的其实不必真的 peek，lastItem/consume 就足够了，而且用 peek 的话 takeWhile 等函数式流操作依然要重写。

现在我有了一个更好的思路解决，也就可以写 example 了。
就是『我的 literate 的 literate 不是我的 literate』，我们认为 (literateBegin (literateBegin ... literateEnd) ... literateEnd) 里层的 (begin...end) 不被外部建项工具和 literate_kt.js 提取

然后就可以用 depend="parent_id" 直接去加隐式依赖就好了，反正每个 begin end 后都有 [Kotlin Code] 按钮的。

<div class="literateBegin" id="emmm"></div>
<div class="literateEnd"></div>

<div class="literateBegin" id="wmmm"></div>

<div class="literateBegin" depend="emmm wmmm"></div> <!--inner literate-->
<div class="literateEnd"></div>

<div class="literateEnd"></div>

实现的模式是这样的：

Literate = <div class="literateBegin *"></div>
(<*> | Literate)*?
<div class="literateEnd *"></div>

我简直失了智了 #JavaScript #ES6

艹，还不如用 FP.js 的解析器呢（笑话

s=new SaveIterator([1,2,3])
Object { s: Array Iterator, last: {…} }

takeWhile(x=>x<2, s)
Generator { }

[...takeWhile(x=>x<2, s)]
Array [ 1 ]

s.lastItem
3

服了。

突然才想起来，其实 Peek/Save 和具体的辅助函数 next() 不 next() 关系都是很大的…… 一个是移动数据流、一个是不移动，根本没法直接兼容 takeWhile，不然是分不清的……

万恶的 ES6，它非得你 next() 才能知道是否 hasNext，或者说能判的时候状态必须改变，好多程序写起来就会麻烦一些

ES6 的 iterator 真是麻烦死了，hasNext/next 根本分不清

我不用递归好了…… 写得像 Scanner 一样，好写一些
垃圾 ES6 Iterator，真是不好用。

#ES6 #JavaScript 的 Generator 实在是太坑了……

本来各种流逻辑搞不清图形思维混乱，结果莫名其妙就试出来了…… 真是面向 debug 编程。

...还是有 bug……所以不能面向守株待兔编程。
瞎猫撞上死耗子

艹，果然只当瞎猫写不出程序啊，虽然思路还是不清晰，但至少还是有那种直觉的。

Literate #Kotlin 总算是基本可用了…… 😢
我总算是可以写那篇关系式的文章了……

#CS #learn 作为程序表达和转化领域的爱好者，我也真是很有福气了，居然能在接触编程两三年后就了解并且实现过 非结构式(x86 intel)、结构式(C, Basic)、面向对象(Java, Kotlin)、函数式(Scheme, Haskell)、关系式(microKanren)、逻辑式(Agda) 这些知名编程范式，实在是感谢许多大佬的分享。

实在是过于写实，我开始回忆起之前我写 ToC Tree 的时候那个苦逼…… #web #JavaScript 前端太难了！

#Kotlin 所以我说，好的代码本身就是文档。何须太多太细的文档弄得让人无所适从？知道怎么用就好了，这是一个复用库的底线。

#PLT 这次绝句的变化主要还是语法的变化，不过不要看不起语法变化，因为它们使得语言更优雅了。

1. 「解量」「解对…里的(模式)……」
变成了 量提 (甲、乙) = 听去一数对()
对用户与索引里的提 (此人、编号)，说("$编号 ${此人的名}")。

新语法类似改「重复当」为「重复若」时一样，更对称了，这不仅仅意味着实现解析器/翻译器会更容易，学起来也会更容易。

2. 「不」变成了现在唯一的『中后缀修饰』

比如 属(is)、存于(in)、是(==)、即是(===)、大(>)
现在都不需要专门定义特定语法了，用户利用自定义记法定义的如 记法「为」的量 为空：真假 取者……
也不需要再对应地定义一个模板化的 不为空 了，因为现在有中后缀否定修饰「不」存在。（这也是Kotlin没有的特性）

3. 『人称』语法被统一了

第一人称是面向对象术语「我」「亲」，表示对象的和对象继承自的事物，只有他们可以有类似 Kotlin 的 label 我[某事]。
label 的引用解析和 Kotlin 差不多，绝句混用了 我[…]/亲[…] 这种语法但其实是没什么问题，因为量本来就不该起成标签有的名字。

「若」、「判」支持第二人称「你」，可以简化「若」条件和体，以及替换 Kotlin 的 when (val x = expr)。
「若」当然也包括「重复若」「重复……若」

「对」同时支持第二人称和第三人称的「它」「他」「她」
中缀链的「」和逗号块都是第三人称的。

a令置为「它+1」
(用户)里去找，他的名字是"某甲"。的项一
青蛙里去找，它的名字是"👓"。的项一

4. Comparable 和 Any 要么必须支持 equals(Any) 要么必须提供 <T> 的问题解决了

就是抄 Rust 的 Self 类型嘛。虽然我不知道类型系统到时候具体是什么区别，我看大概是没什么问题，除非以后编译到 JVM…… 显然不可能很简单地解决。
但绝句也没说非得直接 100% 兼容 Java 啊？

比如 值 里面就可以这么定义：
物 『值』为
“……”
待例、算符的事 试等(另：我属“Self”)：真假

5. 然后还有许多也整理出来的概念

逗号表示法：逗号布局、逗顿句简写、逗号块、逗号取调链 （现在给删了，就是逗号块）
文法层次：常量、言元、言、句、段、体、书