(define (histogram vector-of-words)
(define hash (make-hash))
(for ([word (in-vector vector-of-words)])
(hash-set! hash word (add1 (hash-ref hash word 0))))
hash)

(letrec
([l '(pure monkey made a salted monkey soup)])
(histogram (list->vector l)))

;'#hash((made . 1) (salted . 1) (soup . 1) (a . 1) (pure . 1) (monkey . 2))

所以 #Racket 还是很过程式的？(
从这个角度看，王垠在某个程度上还真是... 很灵性呢... 🙈

https://epsil.github.io/gll/#continuation-passing-style-section

#FP #scheme #parser 想了解 continuation-passing-style （没有 return 如何编程？）的大佬们可以看看这人的文章，我觉得相当好。实用性，王垠那几十行代码不就是 CPS 优化吗。

照例个人观点：
0. 上文定义了 success/failure 的 union ，以及 (successed val rest) failure ，还有添加回调的 (bind p f)，基本是 (match (p s) [(success v rest) (+ v 1)] [failure failure]) 这么用的。
实现的解析器不支持流，支持 substring 。传递方式是 backtrace (比如 (string "abc") 在 (seq) 里成功则 (cons "abc" (cont "")) 失败就只是 failure 单值，所以要利用 memo 函数)

1. PKT 是不需要这种“优化”的（顶多比过程式慢 50倍的纯函数式框架要用），因为我们的 Seq 明白一解析器失败不考虑后面就 return notParsed ，不需要玩 p1(p2(p3 { })) 这种耗栈的游戏。Kotlin 不支持 CPS 优化，编程也不是智商测试。

2. CPS 也是有一定价值的，虽然它会损失一定性能，但能够拿到调用者的句柄（比如在有 Decide 的模式里，就可以后继操作遍历所有分支了，或者进行异步回调"thunk"函数）。和非 CPS 一样可作为 suspend fun 协程

3. 即便这篇文章相对易懂 #Lisp #Racket ，我不建议大家认真用 Racket ，原因是括号的表现力不够

比如文中 (let (result (apply op args)) (entry (mcons args result)) (set! alist (mcons entry alist)) (m=map)一大堆括号，有没有注意到 (let (a v) expr) 只是为可读性而加的，量定义可以内联…… 只是表达 alist = args to op(args) : alist 甚至 alist[args] = result 的意思呢（这例还是SICP里的呢，多余命名量本身就可能意味着语言性能缺失😢，比如『文言文』里甲乙丙丁一大堆OK么）…… 函数式那么多年修成正果了，开始从“无副作用”往“看起来像过程式”靠，草生(*￣m￣)

4. 从解决实际问题而言我觉得 ParserKt 更贴近，但这个文章所创建的解析组合子用更少的代码定义了更广义的实现方法，非常有意思（最后也用左递归和 regex 创建了计算器，缓存和穷举最长匹配问题如此有意思以至于我开始可惜PKT不用处理它了😳），而且也易懂的讲解了 CPS/trampoline 以及“穷举所有可能结果”的正统函数式思路 #Learn