我真的不希望以后在说什么『我希望...』了... 因为好像没有人会关心这些

本频道和之前的 duangsuse::Echo 都非常密集的在发一些类似鸡毛蒜皮的技术相关细节，是的，它们不『内敛』
而且都不是好看的东西，都不是 Geek 和 Geek 程序员们喜欢的东西，它们非常鸡毛蒜皮而且不好看、不实用。
他们很显眼，而且我的确有刻意在宣传一些广播...

但是这就意味着我炫耀、我自负、我不够友好吗？我真的没有把自己喜欢的这些东西当成过表演，我讨厌只是为了做给人看的那种事情... 只是因为我要『分享』，顺便自己学习一下而已。

我真的觉得很奇怪.... 为什么会对我这样，因为之前的几次撕逼？还是因为所有人都发生了改变？因为我自己也背负了什么东西而我没注意到？而且我现在还在炫耀？是因为我没有去做一个隐藏自己的『大佬』？

没人告诉我，我真的猜不到...

唉... 如果真的是这样那还简单了。 我完全可以自己发自己的。
就像本频道，现在关注数平均阅读量不到 duangsuse::Echo 的零头。
实际上我不在乎有多少人看，我在乎有多少人看了以后能理解、明白，得到哪怕是一点点的见识甚至知识、系统的知识甚至新技能，或许以后还做的比我好。

我真的不在意什么阅读量、什么粉丝，我只是想给可能关心的人分享而已

不仅仅我不以阅读量、关注论事，而且对于看到、订阅 ::Echo 的人，其实得知很大一部分（甚至全部，包括之前我以为的一些至少有类似爱好的大佬）都不会关心我现在可能在关心的一些方面的知识后，我真的感觉很失望，我的分享没有起到任何作用，知识被人快速跳过了而已，没有哪怕一个点是被 get 到了的，也没人去编程实践、或者进行理论上的分析。

我觉得哪怕是有人稍微往里面看一点，一点能发现我真的不是在装大佬、真的不是刻意地在做什么莫名其妙的事情、我真的不是在炫耀什么

可惜我没看到哪怕是一个人 真正有 这一点意识，大概他们都去写论文、补习、刷题了（唉...

我真的不懂，为什么『裸体』的知识这么容易被人唾弃、讨厌，难道只有做出好看的东西，那些应用、后端、web、设计，你才有资格去『分享』？难道这些不配出来吓唬人？即使我的这一点分享，连冰山一角都算不上

有能耐的人应该去看看组合子逻辑和形式验证、机器学习、信号处理、程序分析程序变换、算法、PLD(可编程逻辑控制器) 编程，我说的『长文』是多么浅显的内容啊，难道因为这类知识要稍微『不文静』『外向』一点，就是万恶的？因为它在刻意伪装很厉害，真实很废？

难道有人走路就不会都能飞？

现在看来，很多群聊大概是完全无法承受我这闲人的密度吧... 虽然我真的是只发成品的...

我开始觉得这些会貌似占满整个屏幕的分享链接和贴代码是错误的决定，
如果大家 觉得对交流有妨碍的话，请务必要告诉我，我可以发短一些（

🖕 tail

为什么

这是第 N 次了

N=3

没有人称呼我『您』的

所以说我希望你后称我『你』就可以了....

推荐一个博客 #recomended #blog
@yifenshijie （已经废弃，请转到博客）
我很喜欢它的内容，观点很有意思、面向用户方面的技术讲的也很新颖贴近生活

#China #life

Exactly correct. This is why they have nice things in Hong Kong.

我们忘记无关内容，开始讲这个很辣鸡但是依然可以用的解析组合子。

昨天我们说了，如何去解析 satisfy, charP, elemP, kwP, wsP, ws0P 并且提供好看的错误标识
现在是组合解析器的时候了：以上解析器皆可被用于哥哥（貌似）解析器，来实现顺序解析和循环解析（递归不支持，如果需要的话解析程序得自己写）
由于是基于无法重置字符流、简单函数闭包组合的方式，视窗有限并且无法做到在任何解析器失败时都可以重置（消耗的字符已经也只能消耗了，无法回到从前出现第二次）
所以所有这些哥哥 都很废（因为 FP.js 也只是个弟弟...），哥哥不能再组合自己的兄弟、只能组合不消耗字符 / 最多 lookahead 一个字符的弟弟 也是没有办法的事情呢（要不然就要使用 workaround）

seq, possible, lookahead1, someFold, manyFold

+ seq(ps, folder, msgr)
这个哥哥是顺序解析弟弟的。

ps = p.seq([p.satisfy(x => x.startsWith('--')), p.elemP(['mode', 'quiet', 'version']), p.kwP('ok')]); pp = p.run(ps);

> pp(['--version', 'mode', 'o', 'k'])


Either { inner: [ '--version', 'mode', 'ok' ], left: false }

这里我们组合了 satisfy 和 elemP、kwP
注意 kwP 的行为是正常的，它本来就是字符流的解析器（它不叫 listP）
它的行为就是阅读每个项目的第一个字符（在字符流里，这肯定是一个字符而已）、和需要的 keyword 比较，如果成功则判断下一项，失败就完了

如果你使用 possible 和 kwP 的组合，务必注意：kwP 实际上只能区别开头的一个字符，如果有成功的情况，万事大吉
如果失败，请 务必 让 possible 和嵌套它的组合也一起失败，不然就是未定义行为（可能发生莫名其妙的解析错误，因为 kwP 做不出能够在失败时重置输入流的担保）。
比如 cat 和 cab 就分不清了（都是 c 开头）但是能够分出 cat 和 dog（一个 c 一个 d）
（题外话，kwP 这个名字应该改成 stringP 的，此外，它的功能也应该被泛化成列表解析，而非字符串解析....

> ps = p.seq([p.kwP('你好', '我不好？'), p.kwP('世界', '404 Not Found')]); pp = p.run(ps);

> pp('你')

Left('Parser failed @<feed>:1:1 (pos=1@<eof>), sequence item 0: Unexpected EOF. Expecting keyword <你好>@1 我不好？')

> pp('你好')

Left('Parser failed @<feed>:1:2 (pos=2@<eof>), sequence item 1: Unexpected EOF. Expecting keyword <世界>@0 404 Not Found')

> pp('你好世界')

Right([ '你好', '世界' ])
> 

pp('你好世界哈').toString()

'R(你好,世界)'

seq 使用的 match folder(这个名字有点莫名其妙) 真正的魅力在于可以快速创建 AST
比如我们有一门叫做 def 的语言，它的 Item 规则是这样的：
<def> ws name ws0 <=> ws0 value
假设 value 肯定是 "abc" 这种的，则实际上可以这样：

function DefItem(_d, w0, name, w1, _eq, w2, val) {
  this.wss = [w0, w1, w2];
  this.name = name;
  this.value = val;
}

> ps = p.seq([p.kwP('def'), p.wsP(), p.someFold(p.elemP(['a','b','c','d'])), p.ws0P(), p.kwP('='), p.ws0P(), p.someFold(p.elemP(['1','2','3'])) ], p.makeNew(DefItem))
> pp = p.run(ps);

我们试一下

演示方便就不写复杂了

+ possible(ps, msgr)
这个哥哥可以组合很多弟弟的可能性

+ someFold(p, folder, msgr)
这个哥哥顺序解析弟弟、直到解析不了 return f(f(f...(v, x), y), z)

+ manyFold(p, folder)
这个哥哥首先看弟弟能不能被解析，如果不能直接成功 return v，重复解析弟弟、直到解析不了

+ lookahead1(pmap, flmap, msgr)
这个哥哥首先判断 pmap 是个 array 还是个 object
如果是 object，pmap 的 key 是下一个字符的可能性，value 是处理这个可能性的函数
如果是 array，pmap 的 key 是一个谓词函数，lookahead1 以下一个字符尝试找到满足的函数，并且在 flmap 里找到这个函数名字的键，就是它的处理器。
任何不匹配都会导致解析失败

啊... 这个『无论怎么样都要加花括号』『不要使用 i++』原则还真是蛮重要的，我都没有想到可能会被解析成不知道什么样子....

开始我利用了 i++，可是没有想到：

1. 如果某次判定失败，则 for update 块的 i++ 一般来说会运作（但不可能大于 str.length+1，因为那时已经 break (&&短路)）
2. 如果第一次判定失败，则 i 为 undefined，失败
如果成功，则 for 后 i 是 str.length+1，问题是，在 for.predicate 里更新变量... 本身就是很差的编程风格
这样就出现了一个问题：
1. 如果最后的条件不符合，i 会被更新，但是条件实际上不符合，导致了
"你_世_" 这样的也能 match....
人间之鉴...

这类模板化的循环，应该以可读性为主... 这点很多嵌入式软件设计的例子很好，都是模板化的判断
我看不起模板化（实际上我在 JavaScript 这样的层次也使用 C/C++ 的模板逻辑风格），可是这却导致了难以察觉和修复的错误的产生...

另外的一个 #人间之鉴 ：一定要理清思路再下手，尤其是隐式上下文的问题，如果各种加 Workaround，你就会进入无限 REPL 和修代码加 case 狂猜的状态无法自拔，最终会浪费掉大量的时间。 如果成功则最终代码会令人莫名其妙而且往往有比它好十倍的解决方案；如果失败，则你就白白浪费了几个小时的时间...

什么人间之鉴，但的确是有点莫名其妙。这个问题我最终没有解决，
'2' 和 '=' 看起来是一模一样，可我不知道为什么差一个空格两个空格就会有问题

我已经没法去想了，对我来说这真的就是莫名其妙，很对不起，也很对不起我自己... 坐了这么久、盯着屏幕，但是没有任何进展并且模拟的都成功、REPL 全不符合预期，我根本搞不懂，为什么『两边』还不一样，而其他结果全都正确。