最后那个就是非常简单的递归数据构造逻辑，最后的结束扫描只是因为我们觉得『出现比它大的 heading 代表它结束了』而已，如果知道 ending 的话当然应该提早返回

构造出的数据非常简单，思考一下为什么递归扫描（此时把子树的 level 看作根文档）

相关知识，Python、Haskell 的缩进语义也是可以通过类似判断实现的，只不过使用 DOM Tree 接口去解析会方便很多

以上的函数库还要加上一些方便的 operator:

forIter 要能够接受 InterruptedException 来支持内部函数去 breakIter() nextIter() 打断/

take / drop / collect = take.curry1(Infinity)
takeWhile / dropWhile
zipWith(f, xs, ys)
map(f, xs)
filter(p, xs)
iterBy(node, docall('get', 'nextSibling'))
ap(sub, [1,2]) 这种

因为是手写就不 AMD/CommonJS 了
还是支持 ES5 算了，眼花的特性，毕竟 ES5 也老高级了...

JavaScript 面向语言编程应该非常简单的说，使用 副作用的流完成 parser combinator...

这样就 好看 可是不... 总感觉有些东西

这个 dropWhile 本来可以讲一个问题的，可是觉得没有必要讲了（就是一个同时持有当前项和 lookAhead 项目的问题，对于 stream 式的差别只在时序、这里只在最后一次迭代）

一个时序问题，修改前的程序会多迭代一次、跳过流里的一项，现在的程序不会了（移动 n!=0 到前面，短路 &&...）

写各种 list operator 写到手软... 还没有开始写业务逻辑...

#FP #JavaScript #Haskell 🤔 绝对要开始写业务逻辑了...

#Ruby #Algorithm

makeCats('a'..'z', 1)

=> ["aa", "ba", "ca", "da", "ea", "fa", "ga", "ha", "ia", "ja", "ka", "la", "ma", "na", "oa", "pa", "qa", "ra", "sa", "ta", "ua", "va", "wa", "xa", "ya", "za", "ab", "bb", "cb", "db", "eb", "fb", "gb", "hb", "ib", "jb", "kb", "lb", "mb", "nb", "ob", "pb", "qb", "rb", "sb", "tb", "ub", "vb", "wb", "xb", "yb", "zb", "ac", "bc", "cc", "dc", "ec", "fc", "gc", "hc", "ic", "jc", "kc", "lc", "mc", "nc", "oc", "pc", "qc", ...]

递归下来懒得想了，跑路（不过就是每次往上面一层去 map (\x flatMap ([x] ++)) xs

就可以构造出 a (a) b (a) ... z(a), a(b)... a (aa), z(aa), a(ab)....

可以（

#define GETC (ch = getchar())
static inline int readInt() {
signed int n = 0;
char ch = '\0';
while (isspace(GETC));
if (ch == '-') { n = ~n; GETC; }
//reads natural part
while (isdigit(GETC))
n = (n*10) + (ch-'0');
return n;
}

类似解析组合子的布局

总之，现在看起来生成的程序是有差别，不过我觉得还是相信编译优化的好，毕竟这都几十年的积累了，若是真的快它要把普通 add sub mul 指令都优化成位运算的

知乎上之前有篇关于这类问题的描述，可以找找，总之就是这样...

我觉得，把程序写好看是最重要的，各种很 dirty 的 workaround 和手工的变形，能免则免，避免黑科技、避免魔数什么的

希望两位以后的程序，尽可能往简单易维护的方向写... 或许过几天你就会发现简单的价值所在

推荐文章：如何写出无法维护的代码

Have a nice night coding.

的确有点，短谁都是的，不对称无规范是要命的

dijkstra 图搜索也的确是每一步考虑到更多的条件，构造有更多的数据...

我学过 dijkstra 算法（就是主要一个 map 记录某 node(edge) 的最小开销和一层路径，最后根据 end edge 的路径回溯一个一个地方的回来），不过我没写过，而且不是特别熟悉 C++
不过我觉得代码风格是很重要的

良好的代码风格可以证明你拥有清晰的逻辑，何况本来常量、函数、本地变量、全局变量、类型名称使用不同的命名风格本来就有益于使得编程更简单易读

所以，如果可能的话，还是建议 以后尽可能写简洁一点，也不必太拘束（

刻板的缩进风格

不可读的这么多花括号
if () for 只是这种原因的话也要加上花括号，而没有在语法上区分开
不容易符合直觉的