今天有点晚了就写不了那个关系式的了…… 但愿明天，还有为了绝句成功完成必须的 Literate Kotlin 项目生成软件能正常写出来。

fun <V, K> Iterable<V>.hist(key: (V) -> K): Map<K, List<V>> {
  val histogram: MutableMap<K, MutableList<V>> = mutableMapOf()
  for(item in this) histogram.getOrPut(key(item), ::mutableListOf).add(item)
  return histogram
}

listOf(1, "abc", "emmm", -1)

[1, abc, emmm, -1]

listOf(1, "abc", "emmm", -1).hist { it::class }

{class kotlin.Int=[1, -1], class kotlin.String=[abc, emmm]} #Kotlin

先修补下找出，绝句这几天就完善了『第一人称』『第二人称』『第三人称』和中缀链、基本语法模型。

剧透一下，那个关系式的 最后总结有 6 个基本元素：State, Variable, Introduce, Eq, Either, Both

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