Forwarded from Deleted Account
写哭了，我都没有想到
xs 还能变成这种情况，导致流函数不正确，害得我改了半天还加各种带 effect 的表达式....Forwarded from Deleted Account
因为本来很多逻辑就是用带赋值副作用的表达式写的，现在才不得不改成这个样子，不用副作用的话要写一大堆重复的 if else 感觉很辣鸡
还好这是 joinN，如果要单独写 join2 join3 什么的复制一堆 if 根本不能看的好么
还好这是 joinN，如果要单独写 join2 join3 什么的复制一堆 if 根本不能看的好么
fp.js
21.4 KB
#JavaScript 好像是 最终版本 不带 LL(1) parserc 的 FP.js 了（包含多种函数组合操作、惰性+break continue 流、一些 Monad、一些辅助函数 （
/tmp/duangsuse.sock
👋 Sticker
今天我来给大家分享一下心得（迫真） #dev
我昨天和今天都在写一个非常无聊的程序.... 就是一个解析组合子，欸这个知识背景它不需要啊，因为我是来分享写测试的心得的。
这个呢... 我需要写一个蛮复杂的状态机式程序，一个叫 Feeder 的类，它是用来表示用户输入的，就是一个字符流，我需要给它加上 CR/LF/CRLF 的行号和列号支持
至于两者的支持思路比较简单（毕竟之前我写了一个 lookAhead1 的包装流，所以可以同时看到两个连续字符）
不过测试的时候还是出现了一个低级的初始数值问题 — 我没有很好地分析程序控制流和数值断言，弄错了列号的意义：
abc
— ‘\n’ 本身是 col=1 d — col=2
而且因为程序控制流本身不是特别好看（因为有个非常长的带赋值副作用的表达式）
程序测试，就是这一个 next 方法，花了我至少一个半小时的时间，只是由于这个原因...
测试的过程中，我误会了原来错误的一个 root cause，也应用过一个错的修复，但最后暴力通过 REPL 一次一次计算的看知道错误在哪里了
不过上面的内容都很没意思，其实写这些只是想分享一个心得：测试的时候一定要保证测试本身的正确性，要不然测试写错程序通过了，反而可能跟着错... 测试失败了要找原因细想，不要为了通过测试而乱改测试。
我昨天和今天都在写一个非常无聊的程序.... 就是一个解析组合子，欸这个知识背景它不需要啊，因为我是来分享写测试的心得的。
这个呢... 我需要写一个蛮复杂的状态机式程序，一个叫 Feeder 的类，它是用来表示用户输入的，就是一个字符流，我需要给它加上 CR/LF/CRLF 的行号和列号支持
至于两者的支持思路比较简单（毕竟之前我写了一个 lookAhead1 的包装流，所以可以同时看到两个连续字符）
不过测试的时候还是出现了一个低级的初始数值问题 — 我没有很好地分析程序控制流和数值断言，弄错了列号的意义：
abc
— ‘\n’ 本身是 col=1 d — col=2
而且因为程序控制流本身不是特别好看（因为有个非常长的带赋值副作用的表达式）
程序测试，就是这一个 next 方法，花了我至少一个半小时的时间，只是由于这个原因...
测试的过程中，我误会了原来错误的一个 root cause，也应用过一个错的修复，但最后暴力通过 REPL 一次一次计算的看知道错误在哪里了
不过上面的内容都很没意思，其实写这些只是想分享一个心得：测试的时候一定要保证测试本身的正确性，要不然测试写错程序通过了，反而可能跟着错... 测试失败了要找原因细想，不要为了通过测试而乱改测试。
Forwarded from Deleted Account
另外这个是符合优雅性和正确性的，CRLF 折行内本来就不算一行，所以没有行号这回事（所以 CRLF 扫描完 CR 后行号是 -1 有合理性，因为它根本就不应该被视为单独的两行）
优雅性：可以把最后一个 branch 的 (... = false) 改成 true，这样就可以做到自动在 CRLF 的 LF 处『折行』（之后可以判断
优雅性：可以把最后一个 branch 的 (... = false) 改成 true，这样就可以做到自动在 CRLF 的 LF 处『折行』（之后可以判断
--lineNum
实际用起来也正确，可是连续 <CR> <LF> 的 LF 毕竟不算完整的一行，不吼
/tmp/duangsuse.sock
好耶！是我写的第一个解析组合子！
目前这个解析器的设计存在严重的问题： seq, possible 等组合子可以组合很多子解析器，但是子解析器只被设计为对 seq 有效
比如 kwP，它会为 seq 将调用的 next() 使用一次
另外还有 LL(1)-like 本来就存在的问题： 字符阅读后只能被『消耗』，很多看起来正常的组合比如
比如 kwP，它会为 seq 将调用的 next() 使用一次
feeder.duplast() 在需要时免于 nextchar，可是在 possible 里使用，就会导致问题（重复的字符，因为 possible 不会像 seq 一样去 next()）另外还有 LL(1)-like 本来就存在的问题： 字符阅读后只能被『消耗』，很多看起来正常的组合比如
possible(seq(...), seq(...)) 是无法正常工作的（不能在 match 判断完一个 seq 之后，对之后的 seq 也有相同的上下文）