/tmp/duangsuse.sock
23 subscribers
303 photos
3 videos
92 files
337 links
从 duangsuse::Echo (@dsuse) 跟进出来的分支,将在作者恢复原帐号访问的时候合并删除。
Download Telegram
/tmp/duangsuse.sock
总之,现在结构需要优化、修复的还有很多,也有很多冗余构造需哟删掉,啊啊啊啊啊啊 甚至开始怀疑,是不是就不应该采用只可以取一项 / Lookahead 1 的字符流,PEG 好一些呢?
我决定咸鱼,It's a feature! 看!你可以利用 possible 函数,自己再独立实现不能被用于 possible 这样的 wsP, elemP, kwP 这种(啊啊啊,原来组合能力都这么差.... 可是也没有办法啦,流又不能随便重试的也无法实现自由的 possible 组合啊... 是我设计的时候搞错了
... Anti-feature....
/tmp/duangsuse.sock
我决定咸鱼,It's a feature! 看!你可以利用 possible 函数,自己再独立实现不能被用于 possible 这样的 wsP, elemP, kwP 这种(啊啊啊,原来组合能力都这么差.... 可是也没有办法啦,流又不能随便重试的也无法实现自由的 possible 组合啊... 是我设计的时候搞错了 ... Anti-feature....
这样的话技术问题除了 chainRec* 就解决了,possible 的组合项要自己写专门的解析器,不能用 seq 解析的 kwP, wsP 什么的(感觉好没有必要的样子... 虽然本来也就是没法用而已)

someFold 和 manyFold 本身和 seq 差别不大,就是需要判断直到不能解析为止,给 seq 解析设计的组合子还是可以复用的。

现在先保证真正可能消耗字符流的解析器都给 seq 设计(也是没有办法的事情,这不是 PEG 类的流结构,我这个是不能 mark/reset 的...)
然后再去完成复杂一点的组合吧;;;
/tmp/duangsuse.sock
我决定咸鱼,It's a feature! 看!你可以利用 possible 函数,自己再独立实现不能被用于 possible 这样的 wsP, elemP, kwP 这种(啊啊啊,原来组合能力都这么差.... 可是也没有办法啦,流又不能随便重试的也无法实现自由的 possible 组合啊... 是我设计的时候搞错了 ... Anti-feature....
啊, 不对,想了一会,我知道了,我知道自己在干什么了、我知道 nextItem 到底是该怎么用、为什么要有 duplast 函数了
其实是我的基本解析组合子写的不对,如果任何解析器解析失败,都应该 revert 掉自己对流之前的消耗
可是对于大的解析组合来说,他们做不到,但 charP, satisfy, elemP 还是做得到的,这点我之前没有注意到

而对于 seq 和 possible 组合,他们接受的都是 fail 或者不消耗的时候自动 revert 读取的组合子,
possible 也一样,虽然 possible 本身不 next,可是 possible 接受的所有解析器只判断一个项目并且保证失败恢复流,我只需修改 duplast 使它只能重置一回 lastItem 就可以了(?
This media is not supported in your browser
VIEW IN TELEGRAM
想想看 seq 的方式和 possible 的方式还可能是无法调节,重置,可是如果是在 possible 里,如果让 possible 处理这个不一致则会显得莫名其妙(而且很难看,因为目标是 next,如果一个成功什么都不做、如果一个失败你还得 next 一下,莫名其妙)

我还是决定.... 不要 possible 算了,possible 的用户都自己写。

some, many 组合应该不受影响(他们也是每项 next 的,解析不了让子解析器重置就可以了)。
seq, possible 的失败就应该炸了(反正也没法恢复,因为流只能安全撤销一个字符... 还是看 lookAhead1 存在的份上)
行!很完美
这堆松耦合的函数,通过一个通用的返回值模板,居然真的可以正常工作!
/tmp/duangsuse.sock
行!很完美
还好,虽然因为本身流只能处理一个字符的失败,所以不能重置大组合的失败... 小的处理的就没问题
/tmp/duangsuse.sock
行!很完美
强耦合的解析『组合子』
现在这个样子... 根本不成体统嘛,稍微难看的组合 就会出错
解析一下,还得考虑自己的调用者,是顺序派的(调用自己后 next 一下)呢,还是选择派的呢(调用完不 next...)
还不如自己去 next 算了... 这样自己 ungetc 一次,和 seq 不 next,自己 next 一次 有什么区别...
fp.js
30.3 KB
令人头晕的 FP.js... 我不打算继续写测试了,还是拿它立刻 写点解析器出来测试吧 #FP #parser #PLT #JavaScript, 何况 FP.js 提供的解析器,本身就存在很大问题,不是实际应该使用的
/tmp/duangsuse.sock
fp.js
完成的孙(划掉)子(不能添加子解析器的)解析器:
satisfy, charP, elemP, kwP, wsP, ws0P

爸爸解析器
seq, possible(万恶...), lookahead1, someFold, manyFold

辅助
run, pmatch, pfail, parsed, presult, Feeder
写完 chainl / chainr 以后,这个为期三天的努力就告一段落了,我会继续开发那七八个插件... 好人一生平安
究极迫真版本(跑 Done. 194 APIs tested, 388 passed / 0 failed in 0.942 secs.
#FP #JavaScript 我真的无力维护了,赶快开发应用跑路
#JavaScript #FP 分享一些十分不得了(迫真)的心得:我修复了 dropWhile 函数,然后这里我写了惰性递归的 makeCats 造猫(绝望) combination 函数,无论输入数据有多长、重复多少遍都可以利用惰性求值工作,不会像辣鸡过程式一样卡住(数据窗口太大了)
Forwarded from Deleted Account
递归惰性求值的 combination,你调用

const fp = require('./fp');
let xs = fp.stm.lazyCombination("abcdefghijklmnopqrstuvwxyz")(1926);
fp.stmaux.take(100, a);

都可以,反观非惰性求值版本的,反向的数据窗口大小太大了,根本算不出来。(不过递归也可能栈溢... 只能都惰性求值最好)

const fp = require('./fp');
let xs = fp.stm.combination("abcdefghijklmnopqrstuvwxyz")(1926);
fp.stmaux.take(100, a);
// 卡住