大意就是，除了异常以外没有办法在两层 LayoutPattern.read 之间传递控制权，因为使用处是不确定的
除非使用 abstract class 硬性建模何时开启新 pattern，否则这个信息没法通过返回值传递出去，即便能手写起来复杂性也不可接受。

LayoutPattern 注定是递归结构，所以 caller 必须去 handle 它的 closing indent level 返回值，对应用来说那必须手写模板代码，我觉得比起那样还是异常靠谱一些（虽然不可能有泛型，要强制转换了……）

这个和 infix pattern 不一样，它毕竟得是一个 unstable feature……

现在这么实现最主要的问题是得有一个 level 0，不能让异常漏处 Pattern 模型的范畴……

好像不必了，因为每层都是 if (baseLevel > indent) return reducer.finish() 的嘛

#China #freedom 😢休了三天假，发现 CloudHammer 的端口变了，换了个 endpoint，又可以用了

最终我决定还是采取内部递归数据结构的方法来解决，因为异常会打断所有没有特别支持 LayoutPattern read 的子 Pattern read，不能把已经解析到的数据收集回来

比如说解析一个 2D 布局的列表：
[] where
abcs
123s
[] where
winnie
donkey
具体的架构 很难说明白
但是异常一抛，调用 Layout read 的子解析器的 collect 过程就会被打断，最后 abnormal terminate 什么都不能返回

我知道，现在还是 one-pass 的，我决定还是用另外一种不依赖外部递归，直接把 nesting tree 和 visitor 做到框架里支持的另一种方法

直接在内部做好递归解析的问题，不依赖外部了，然后 layout 的开启就分

item@(function somefn) tail@(where)
  ...children

item tail children 三个来保证，直接在框架里递归解析，然后收集结果也是在框架层做、用户用 Visitor 去翻译到目标 AST

针对 ParserKt 的破产重整已经开始了，这是第 9 次相关设计模式的重写……
https://github.com/duangsuse-valid-projects/Share/blob/master/Others/kt_misc/pkt_9/Parser.kt

#life #Haha #dev

下午的时候我又被怼了😢

好可怜呦
可怜之人必有可恨之处

嘛，说着玩玩，iseki 不要伤心

被dalao怼是很平常的事情，不必记在心上，该干啥干啥

你造么，这是我当年在本地最好的初中上学的时候班主任对我说的话。

现在把它送给你

最后祝你 身体健康

标题我都想好了，《地区头校班主任对学生说了这么一句话，竟改变了他的一生！》

哈哈哈哈哈哈 闹着玩的，我又不做媒体

既然 iseki 都被大佬喷了，那我就在这里直播 y=1; x=y=z 的 unify 过程 #PLT

首先说说我们的目标是求得 x=1; y=1; z=1，使用的方法是 unification —— 利用相等关系，让两个 Value(Val/Var) 在一个 State 里实际上划上等号

而一个 Var 呢，我们可以认为是一个 "Symbol"，它的 equals 实现为全等 (x === y)，就可以了。

microKanren 有 six primitives: State, Variable, fresh(introduce), Eq, Either, Both
前三个是最基础的 unification 需求，后三个是关系式编程(relational programming) 里最重要的关系

毕竟是在 Telegram 直接写了，我就不说 Either 和 Both 这种高级操作了（它们能 satisfyIn 的 state 都可能不只一个）

fun main(vararg args: String) {
  val xyz = State()
  xyz.intro("x", "y", "z") {
    val (x, y, z) = it
    y.eq(Val(1))
    x.eq(y); y.eq(z)
  }
  println(xyz) //State{x: 1, y: 1, z: 1}
}

在 Kotlin 里面以 EDSL 的风格 去完成……
首先我们依赖的需要知道啥东西能够 unify 又怎么去 unify，或者说我们得对 Value 的子类型实现 unifyIn(state, other) 操作

我们知道相等关系是有对称性(symmetric) 的 (x=y, y=x)，所以“解构”式的操作只需要有一边定义就 OK 了，然后因为 Kotlin 是强类型的可以加入类型检查。

typealias Consumer<T> = (T) -> Unit
typealias MonoTriple<T> = Triple<T, T, T>
typealias MonoPair<T> = Pair<T, T>

typealias StateMap = MutableMap<Value.Var, Any?>
typealias Variable = Value.Var

class State(private val map: StateMap = mutableMapOf()): StateMap by map {
  fun intro(x1: String, x2: Sting, op: Consumer<MonoPair<Variable>>) {
    val xs = bind(x1, x2)
    op(Pair(xs[0], xs[1]))
  }
  fun intro(x1: String, x2: String, x3: String, op: Consumer<MonoTriple<Variable>>) {
    val xs = bind(x1, x2, x3)
    op(Triple(xs[0], xs[1], xs[2]))
  }
  fun bind(vararg names: String): List<Value.Var> {
    val variables = names.map(::Variable)
    for (variables
    return variables
  }
  override fun toString() = "State$map"
}

interface Unifible<T> {
  fun unifyIn(state: State, other: Unifible<T>)
}

sealed class Value(open val value: Any?) {
  data class Val(value: Any?): Value(value) {
    override fun toString() = "Val($value)"
  }
  data class Var(val name: String, val binding: State) {
    override fun equals(other: Any?) = this === other
    override fun hashCode() = super.hashCode()
    override fun toString() = "Var($name)"
  }
}

艹我写不下去了，太长了

具体怎么实现 unify 以及 unify 的对称性的代码复用留给 iseki 大佬自己研究去吧，我重写我的 ParserKt 去了……

提示一下，
Var unify with Value 都是 assignIn(state, other.value)
Val unify with Value 都是 check，如果 equals 就直接完了，否则 exception
对称性 this unify other; other unify this 的时候出异常可以 catch 然后上 has-exception logical or
此外我写错了一些地方，草

你可是自己说要学习的哦 🌚