/tmp/duangsuse.sock
FP.js 还差一点用于惰性计算流的操作吧...
噢... 其实 join (concatN) 就可以用于 concat2... 所以说是完全可以全部惰性计算的
Deleted Account
使用 FP.js 的话，也可以这么写： const fp = require('./fp'); let makeCats = fp.stm.foldn.curry2(v => fp.fn.bound(v, 'concat').also(console.log)( fp.stmaux.collect(fp.stm.joinMap(x => ['a' +x, 'b' +x, 'c' + x], v)) ), ['a', 'b', 'c']);
const fp = require('./fp');
let { foldn, join, map: smap, joinMap } = fp.stm;
let stmb = fp.stmbase;
function makeCharCats(chars) {
return foldn.curry2(
xs => join([joinMap(x => smap(c => c+x,chars), xs)
, xs]), chars);
}
module.exports = makeCharCats;
FP.js 不对流函数在一次 _done() 之后再次调用依然返回 _done() 作保证，相关问题在查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 一次一次计算的看知道错误在哪里了
不过上面的内容都很没意思，其实写这些只是想分享一个心得：测试的时候一定要保证测试本身的正确性，要不然测试写错程序通过了，反而可能跟着错... 测试失败了要找原因细想，不要为了通过测试而乱改测试。