也不是 10 行之内我实现不了这个逻辑，就是写太弱类型化，感觉总是不合适（虽然JS本该如此😳
理论上这个前端虽然滥用面向对象，他的性能应该是比我高的，毕竟我是 EDSL （就要创建只含数据的字句对象）而非提数据元编程（突然觉得中缀算符优先级对DSL挺重要的啊…… clickingOn .action adds (.wtf on div) 不比纯左结合优雅）
这个就是看起来还可以，语言实现像是视图实现教程附赠的
所以我写严苛点吧…… 搞得我还没有前端熟悉编程和消模板一样
不过在重构原作者一个不会写的线性查找时我也糊涂了，
没有定义无符合的情况
原作者很不明智地新建了 codeBlock 这个同义词变量，其实应该是
，看看这个 while 的穷举居然不可以重构掉（废话），实在是草生
理论上这个前端虽然滥用面向对象，他的性能应该是比我高的，毕竟我是 EDSL （就要创建只含数据的字句对象）而非提数据元编程（突然觉得中缀算符优先级对DSL挺重要的啊…… clickingOn .action adds (.wtf on div) 不比纯左结合优雅）
这个就是看起来还可以，语言实现像是视图实现教程附赠的
所以我写严苛点吧…… 搞得我还没有前端熟悉编程和消模板一样
不过在重构原作者一个不会写的线性查找时我也糊涂了，
while (i--) {code=codes[i]; if (p(code)) break;}
没有定义无符合的情况
原作者很不明智地新建了 codeBlock 这个同义词变量，其实应该是
rfind(p, xs) { var i=xs.length; while (i--) { if (p(xs[i]) return xs[i] } return null; }
，看看这个 while 的穷举居然不可以重构掉（废话），实在是草生
今天下午在实现 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 .