🌚 不好意思，这位叫 习近平 的订户，请问我把你留在频道里（目前只有 8 人...）会不会很危险呢？（ #Telegram #Haha

毕竟这里不是党组织，看起来在习大大大监视下以后不和谐的因素得屏蔽了（惊吓

#Low #China #life

现在我在写 FP.js 的 parser 组合子，等到测试写完了，就可以用 FP.js 的组合子风格来写各种解析器了（

#Haha #MS

你 TM 自己选吧！—— Outlook

今天我来给大家分享一下心得（迫真） #dev

我昨天和今天都在写一个非常无聊的程序.... 就是一个解析组合子，欸这个知识背景它不需要啊，因为我是来分享写测试的心得的。

这个呢... 我需要写一个蛮复杂的状态机式程序，一个叫 Feeder 的类，它是用来表示用户输入的，就是一个字符流，我需要给它加上 CR/LF/CRLF 的行号和列号支持

至于两者的支持思路比较简单（毕竟之前我写了一个 lookAhead1 的包装流，所以可以同时看到两个连续字符）
不过测试的时候还是出现了一个低级的初始数值问题 — 我没有很好地分析程序控制流和数值断言，弄错了列号的意义：
abc
— ‘\n’ 本身是 col=1 d — col=2
而且因为程序控制流本身不是特别好看（因为有个非常长的带赋值副作用的表达式）

程序测试，就是这一个 next 方法，花了我至少一个半小时的时间，只是由于这个原因...
测试的过程中，我误会了原来错误的一个 root cause，也应用过一个错的修复，但最后暴力通过 REPL 一次一次计算的看知道错误在哪里了

不过上面的内容都很没意思，其实写这些只是想分享一个心得：测试的时候一定要保证测试本身的正确性，要不然测试写错程序通过了，反而可能跟着错... 测试失败了要找原因细想，不要为了通过测试而乱改测试。

心得就是一句话（迫真）：不要为了通过测试而写测试，要为了保证程序符合预期而测试，不符合要两边找原因。

另外这个是符合优雅性和正确性的，CRLF 折行内本来就不算一行，所以没有行号这回事（所以 CRLF 扫描完 CR 后行号是 -1 有合理性，因为它根本就不应该被视为单独的两行）
优雅性：可以把最后一个 branch 的 (... = false) 改成 true，这样就可以做到自动在 CRLF 的 LF 处『折行』（之后可以判断 --lineNum
实际用起来也正确，可是连续 <CR> <LF> 的 LF 毕竟不算完整的一行，不吼

好耶！是我写的第一个解析组合子！

如果能用它重写 GeekSpec 就大赞了！去你娘的 PEG！

目前这个解析器的设计存在严重的问题： seq, possible 等组合子可以组合很多子解析器，但是子解析器只被设计为对 seq 有效

比如 kwP，它会为 seq 将调用的 next() 使用一次 feeder.duplast() 在需要时免于 nextchar，可是在 possible 里使用，就会导致问题（重复的字符，因为 possible 不会像 seq 一样去 next()）

另外还有 LL(1)-like 本来就存在的问题： 字符阅读后只能被『消耗』，很多看起来正常的组合比如 possible(seq(...), seq(...)) 是无法正常工作的（不能在 match 判断完一个 seq 之后，对之后的 seq 也有相同的上下文）

目前存在问题的版本

我现在也很迷，究竟是要做到怎么样的程度... 好像完全把判断要不要 next 的逻辑做到 seq 里也是不可以的，大概只能针对 seq 和 possible 两种情况特设吧

现在想要完全抛弃旧的组合策略是非常困难的事，因为 — 已经是这种滥用的样子了... 本来要是给每个解析器决定是否自己管理 next()，也是很容易的事情，可现在却没有那么简单了（各种 workaround） 可是不重构的话，很难实现 possible 这种组合子....

总之，现在结构需要优化、修复的还有很多，也有很多冗余构造需哟删掉，啊啊啊啊啊啊
甚至开始怀疑，是不是就不应该采用只可以取一项 / Lookahead 1 的字符流，PEG 好一些呢？

我决定咸鱼，It's a feature! 看！你可以利用 possible 函数，自己再独立实现不能被用于 possible 这样的 wsP, elemP, kwP 这种（啊啊啊，原来组合能力都这么差.... 可是也没有办法啦，流又不能随便重试的也无法实现自由的 possible 组合啊... 是我设计的时候搞错了
... Anti-feature....