#tools #audio

#Telegram var lastMsg = g.history[0]; val isAh={t:String -> t.all{it == "啊"} && t.length > lastMsg.text.length || t.length <= 3 } ; onNewMessage { if (it.user == lastMsg.user || isAh(it.text.replace("AhAhAh","啊")) ) +(it.delete()) else lastMsg=it }

草，暴力 try-catch 查找么 #tools

def trySearch(op, xs):
for x in xs:
try: return op(x)
except Exception: pass

def searchDecode(cs, text):
print("s = s.encode(%o).decode(\"utf8\")")
return text.encode(cs).decode("utf8")

def decode(text): trySearch(lambda cs: tryDecode(cs, text), encoding.charsets)

btn.onclick = ()=>ta.textContent=py["decode"](ta.textContent)

#dalao #oi

现在脑子里完全是一团乱麻，我之前从没写过基于 Annotation Processor 的 codegen ，完全不知道怎么区别生成结构和复用结构更好

固然我是知道查询字段只要提供文本常量 ，但我不清楚倒底在哪区分不同底层(MutableMap/Mongo/SQLite) 的支持性，以及要弄个 channel 评论的 bot 而需要三个关系是不是认真的，毕竟靠 Grouping<BroadcastId, MsgId> 就可以反向查找到评论板和 getList ，那么利用关系型模型的价值到底在哪，是否要为这种情况支持原生后端

甚至，有没有必要对这玩意支持 JSON 序列化，从而用 tg 的 message 存储这类数据，如果要实现那那么多生命周期、细节我该怎么办？😱

不愧是最怕实际工程的 duangsuse ，希望以后有了 LiterateKt 的帮助我能多开点坑吧。

我去看了下 Mivik 酱之前发的 kamet 编译原理实践博文，注意到他建模的 DFA 大概是 Array<List<Pair<CharRange,Int>>>
也就是每一点都类似 when(state) 0 -> 里 when(c) { in 'a'..'z'' -> state=1 } 这样

我的方案有点区别，是铺平的 Array<Triple<String,Int,Int>> (实际上肯定是 ArrayList ，因为动态测量状态数必须 a. 将函数直接构造 StateMover 变为构造中间结构，带来回收开销 b. 调用函数两遍，一遍只返回状态数来求和，类型上不优雅且做了无用功，结合其惯用法总体看不值得，就像 C string 的 strlen+strcat 也很弱智)

这种方法也能表示 DFA （好比把 when 转为嵌套 if ，一个节约时间一个节约内存），总体上我还是选择了把 when 转成多层 if elif，因为受不了那么多 MutableList (有点 Lua 的气质了…… 不敢用数组只会链表)

这个要反编译回 DFA 的话就要合并测试链了，如
("a", action(0), 1)
("b", action(1), -1)

就要变成 mapOf("a" to 0, "b" to 1) 这种，读取法是

readMap m (t, -p, n) { m[t] = p; readMap m cs[n] }

这个方法只能串联起 action (p<0) 的部分，唉反编译算法递归起来就是麻烦... 还好我不打算写

他也提供了一个方法手动建立 DFA ，当然也可以由 NFA 子集合并法优化而来，之后 Parser.kt 的写法是 LR(1) 也即递归下降法(left-right recursive descent, 不过这个缩写好像有 left recursive 的意思)

ParserKt 对此类算法的需求仅仅是 lexer 跳空格层面而已，所以没有严肃到独立实现一个 regex 匹配

谈到解析器框架的设计，函数式那边都是 StringView: get/length/drop(n) 和 Regex/Substring match 整个输入 String 作 lexer (因为 re 不支持字符流匹配) 的货色， ParserKt 算是两边的混血，拒绝函数式的啃本和工程派的复制粘贴

如今终于完美解决跳空格问题了，还是同时依仗了函数式的简洁和状态机的非阻塞，当然也离不开对部件重要性的正确评估（拒绝跑题），只有多范式互补才是 Kotlin 的正统啊！