现在这个程序是这个样子，咱来看看。

我们举一大堆输入示例，然后一步一步算。

1 — scanInfix() ?: return atomAt0
1 + 1 — op1=(+), [Base(1)], rhs1=1, [Base(+ join 1, 1)]
1 + 2 * 3 — op1=(+), [Base(1)], rhs1=2,
op2=(*), [Tail(1, (+)), Base(2)]
看到了吗？上面 ^
就是第一个『等待结合』的情况，我们又回到了「递归」的原点 — 一次递归扫描的开始
当然，这里我们的 tail 会直接 reduce 一次，显然它必须保证当前栈顶一定是 Base
这是可以保证的，因为我们在每次 push 上 Tail 的时候，都会接着 push 一个 Base，而第一次 push 的是一个 Base。

比如说，假设有 () 优先级大于 (*)，0 + 1 * 2 3 显然需要 [Tail(0 +), Tail(1 *), Base(2 3)] — 扫描 op1=() 的时候 scanInfix() 失败，于是它会直接开始规约过程
可是这个栈它是这么构造的：
[Base(0)]
[Tail(0 +), Base(1)] op1=(+), op2=(*)
[Tail(0 +), Tail(1 *), Base(2)] op1=(*), op2=()
[Tail(0 +), Tail(1 *), Base(2)] rhs1=3, op1=(), op2=fail
找不到比较的第二个参数，中缀链扫描完毕，开始回溯组织语法结构。

[Tail(0 +), Tail(1 *), Base(2 3)]
[Tail(0 +), Base(1* (2 3) )]
[Base(0 + (1* (2 ** 3)) )]

至于我要写成连 [Tail(...), Tail(...), Base(...)] 都兼容的模式，用reduce，是没道理的（因为相邻两项都会自然折叠好的……）。
好吧，其实是有道理的，这样会优雅一些（迫真）

进一步优化还可以用 JDK 的 Thread local storage，因为每个线程同时只能运行一个函数。
换句话说一个线程对 infixChain() 函数调用有一个栈就够了，用完 clear() 就可以，这是个存储分配方面的优化。
当然，如果你的那个 fun 是 suspend fun 当我没说

为了兼容性这个优化我没有做。

运行的时候就是这样

结合就是这样结合 (1 + 2 ^*)

然后你接着往下输入 +1, 到扫描下一个 infix 的时候它要阻塞等待输入

最后你要回溯的栈就是这样 (1 +) ((2 * 3) + 1)，得 8。

然后咱再来测试一下 0 + 1 * 2 ** 3 这种情况，假定 (**) 也是左结合的：
一确保算法在多个 Tail 同时出现的情况下（看起来）可以正常工作。

咱先改一下咱的Op定义，加入新的中缀

我们可以注意到，因为代码结构复用良好，所以没花多大力气我们就支持了一个新的中缀运算符（而且轻松解决了左右结合的问题）。

咱的词法分析器也不需要修改，因为它是这么定义的：

scanSpaces(); return if (peek in Calc.Op.keys) Calc.Op[consume()] else null

咱输入：0+1*2!3
的意思是：0 + (1 * (2 ! 3))

咱回溯的时候是这样的，
2 ! 3 (2%3)的结果是 2

看来咱写的代码不对……？

的确不对…… 0+2*3!4 明明应该成[Tail(0+), Tail(2*)] 的

噢是我定义新前缀的时候搞错了，本来是 ascending order 的 🐱

0+2*3!4!1

现在咱看看这个的临时栈

我们注意到，本来是 0+ 2*
(0+) 的提前和 2 弄混了…… 都是在扫描 rest 的时候搞的
看来还是思路错了…… Tail 是不可能被铺平的，除非你真不用伪递归（就是基于 Recursion<T> 的递归）

突然觉悟了，为什么 Tail 里面必须是 Atom 啊？也可以是递归的 Tail 啊！
不过这样就等于是白建一个栈了……

我想到一种很自然的解决方法：

把栈表达为 [Base(0), Tail(+), Base(2), Tail(*), Base(3!4!1)] 的形式
然后我们回溯的时候修改一下策略，让它结合 lhs=pop() 就可以了

新程序！

好像没问题？ （0 是 3!1 的结果）

0+1*(2!3) 准备回溯。

回溯完成，得 2 正确。
每次由归纳程序 reduce 从栈上 pop 出一个项目
如果是 join，则 join 又会从栈上 pop 一个项目，作为 reduce 的 base

不过这样实际上就作了一个断言：栈后面的全是结合性弱的，而且这部分全都是往右结合

我相信这断言是正确的，因为如果有打破它的情况，早就在 stack.mapTop {} 的时候被结合了

新的，带基于栈的 infix 链扫描算法的 Calc.kt 例子