今天下午在实现 Tokenizer DOM/JS 应用（基本就是包一下 Trie 树，方便咱唱有日文假名字的歌用的，这个功能苹果有，网易云音乐早就该加了哼。）
因为这个家伙设计得比较方便，可以查看字典树结构和合并后的词对应关系表（而且还能用来查单词……带自动补全草），必须设计一个字典树 string-value 遍历算法。
这个算法咱在 ParserKt 里实践过（毕竟字典树是一遍过解析关键字的重要结构），那时候写了一个纯函数（优点是没有参数所以直接 public 即可），大概就是各种 flatMap 修改合并下一层递归返回的列表啊，麻烦死了，而且性能不高
字典树这个结构也没比嵌套 Map (K-V 里 V 是 Map 的那种) 复杂多少，就是每层映射本身多对应一个『节点本身的值』而已 (比如 "stand", "standby" 里 "d" 也有存值，这种很常见的)
开始我避免了使用递归算法（虽然我最爱写递归算法了 误），想想这个遍历是嵌套 1-N 次组合，肯定要用栈，当时觉得有 keySeq, stack 这两个栈就够了（对应关系是
我开始发现现在写的算法虽然都很麻烦，但就像是思考“通项公式”一样，就是一个状态机或者操作一两个结构，明白了就很简单。
写的是每层 Trie 先给其值（如果有），然后访问它的子节点，这时候我就发现为了能递归完成这个动作，循环必须可以打断（循环的 label TypeScript 是支持的，然后要保存索引……）
我把 for in 变成
写了好多次显式栈之后，我果然还是觉得递归好，至少不需要你加 hack 。
一天半后，项目完成了，然后我突然想到了一个 #Kotlin #coroutine 必须要 executor 来执行的理由(之前一直搞不懂 runBlocking, launch 什么的是干嘛)
一个协程 yield 后要把执行权交出去，如果只是用 CPS (理解为无返回，只 callback ，但在这里收 callback 的还能恢复协程) 的话会造成调用栈不断增长，所以不能直接这样干，只能先把 Continuation 交给收它的地方，返回调度器取任务继续
关于 await/async 不知道能不能完全只用 CPS 变换来实现（反正我觉得实现起来枚举语法生成很复杂），但完整的协程是可以的。
因为这个家伙设计得比较方便，可以查看字典树结构和合并后的词对应关系表（而且还能用来查单词……带自动补全草），必须设计一个字典树 string-value 遍历算法。
这个算法咱在 ParserKt 里实践过（毕竟字典树是一遍过解析关键字的重要结构），那时候写了一个纯函数（优点是没有参数所以直接 public 即可），大概就是各种 flatMap 修改合并下一层递归返回的列表啊，麻烦死了，而且性能不高
字典树这个结构也没比嵌套 Map (K-V 里 V 是 Map 的那种) 复杂多少，就是每层映射本身多对应一个『节点本身的值』而已 (比如 "stand", "standby" 里 "d" 也有存值，这种很常见的)
开始我避免了使用递归算法（虽然我最爱写递归算法了 误），想想这个遍历是嵌套 1-N 次组合，肯定要用栈，当时觉得有 keySeq, stack 这两个栈就够了（对应关系是
stack[i] = keySeq.subSeq(0,i-1).fold(routes) { it,k -> it[k] } ，主要是缓存路径结果）我开始发现现在写的算法虽然都很麻烦，但就像是思考“通项公式”一样，就是一个状态机或者操作一两个结构，明白了就很简单。
写的是每层 Trie 先给其值（如果有），然后访问它的子节点，这时候我就发现为了能递归完成这个动作，循环必须可以打断（循环的 label TypeScript 是支持的，然后要保存索引……）
我把 for in 变成
o[Object.keys(o)[i]] 这样可以保存迭代状态（ES6 也不支持 ObjectIterator ，然后 Object.entries 在 TS 上很麻烦），写出来了（递归的话直接把 i 给 push 上去 然后 i == length 的时候就 pop），现在也感觉好不爽啊…… 索性又换成了带副作用的递归的形式。写了好多次显式栈之后，我果然还是觉得递归好，至少不需要你加 hack 。
一天半后，项目完成了，然后我突然想到了一个 #Kotlin #coroutine 必须要 executor 来执行的理由(之前一直搞不懂 runBlocking, launch 什么的是干嘛)
一个协程 yield 后要把执行权交出去，如果只是用 CPS (理解为无返回，只 callback ，但在这里收 callback 的还能恢复协程) 的话会造成调用栈不断增长，所以不能直接这样干，只能先把 Continuation 交给收它的地方，返回调度器取任务继续
关于 await/async 不知道能不能完全只用 CPS 变换来实现（反正我觉得实现起来枚举语法生成很复杂），但完整的协程是可以的。
duangsuse::Echo
今天下午在实现 Tokenizer DOM/JS 应用（基本就是包一下 Trie 树，方便咱唱有日文假名字的歌用的，这个功能苹果有，网易云音乐早就该加了哼。） 因为这个家伙设计得比较方便，可以查看字典树结构和合并后的词对应关系表（而且还能用来查单词……带自动补全草），必须设计一个字典树 string-value 遍历算法。 这个算法咱在 ParserKt 里实践过（毕竟字典树是一遍过解析关键字的重要结构），那时候写了一个纯函数（优点是没有参数所以直接 public 即可），大概就是各种 flatMap…
嗯…… 现在 github.io 没了，只好看看 coding pages 副本吧
这个墙烦死人了，还要不要程序猿活了，日你妈（指
https://github.com/duangsuse-valid-projects/Share/blob/master/HTMLs/Tokenizer/Tokenizer_es5.ts
https://duangsuse-valid-projects.github.io/Share/HTMLs/Tokenizer/?simple=a_dict.txt+a_dict.txt%3Ea_dict.txt&reverse=~a_dict.txt&text=Hello%20Rolld
这个墙烦死人了，还要不要程序猿活了，日你妈（指
https://github.com/duangsuse-valid-projects/Share/blob/master/HTMLs/Tokenizer/Tokenizer_es5.ts
https://duangsuse-valid-projects.github.io/Share/HTMLs/Tokenizer/?simple=a_dict.txt+a_dict.txt%3Ea_dict.txt&reverse=~a_dict.txt&text=Hello%20Rolld
GitHub
duangsuse-valid-projects/Share
🐕 duangsuse's shared files(e.g. productive software projects, documents) - duangsuse-valid-projects/Share
Tokenizer 支持了计划的最后一个特性——用于支持英语分词的 inword grep
Coding-Pages
Tokenizer 分词器
利用建-值对应字典进行组合、处理文本序列、查询单词
duangsuse::Echo
Tokenizer 支持了计划的最后一个特性——用于支持英语分词的 inword grep
This media is not supported in your browser
VIEW IN TELEGRAM
索引 slice (视口计算) 起来还挺麻烦的，开始用脑子都搞错了，亏了我的工程/调试经验…… 勉强试出来了 😥
老实说我对这个内带优化元素的特性本身认知都不明确，不过终于是写出来了
改日，这个项目会被重写打包成支持 ES5 的 Web Extension ，感谢 #TypeScript .
老实说我对这个内带优化元素的特性本身认知都不明确，不过终于是写出来了
改日，这个项目会被重写打包成支持 ES5 的 Web Extension ，感谢 #TypeScript .
duangsuse::Echo
索引 slice (视口计算) 起来还挺麻烦的，开始用脑子都搞错了，亏了我的工程/调试经验…… 勉强试出来了 😥 老实说我对这个内带优化元素的特性本身认知都不明确，不过终于是写出来了 改日，这个项目会被重写打包成支持 ES5 的 Web Extension ，感谢 #TypeScript .
现在为了支持新的 UCD (Unicode 字符典) 带来的性能问题，尝试为 iter, tokeize 支持惰性下层 Trie routes 的初始化（以前的 Kotlin 版本是每层存 value 而不是字典里存的，就不需要专门考虑惰性问题）
现在单单只有 Object 到 Map 的性能提升，还不足以到处理普通话发音字典的程度，麻烦死了。
足足卡了我一天，问题解决不了 WebExt 当然也难产了。
现在单单只有 Object 到 Map 的性能提升，还不足以到处理普通话发音字典的程度，麻烦死了。
足足卡了我一天，问题解决不了 WebExt 当然也难产了。