我顿悟了！bytesToIntegral(zero, shl, or, bytes.iterator()) 是内联的，所以它里面的 accumulator = zero 实际上一直指代的是一个只读的参数？

还是不行…… 简直莫名其妙

赣！原来是因为我的 ByteUnion 写错了…… 当时是复制粘贴没多想

java.lang.AssertionError: expected:<2008796381> but was:<-17545>

现在就暴露出底层的一个问题，Java 侧使用的是 read():Int 的 InputStream，因为默认是读 unsigned byte，而我要么进行 Byte.uExt() 要么改回原来的封装，要我改回来是断然不可的
可是那样就出现 unsigned.toByte().uExt()，莫名其妙多了两个计算，该死没无符号的 Java

只好弄个 typealias Nat8 = Int，然后改回来算了，免得 uExt 来 uExt 去的，而且那个还要 if <0 判符号位，相当麻烦

唉简单也有简单的难处，要是 Jawa 支持 unsigned integers 就不必操心了

"It works, it works!!!"

虽然我又修复了 N 个 bug，并且是通过迫真调试而非理智分析找到才能用的，但还是能用，这就是……！！！

其实支持如果仅仅有 ushl 这样的支持也不吼啊，因为数值带不带符号位说到底表示上还是有大区别

现在我有点混淆 Nat8 和 byte 这两个概念的意思……
规律就是：只要和 Nat8 不直接相关的（比如一个函参名），都叫 byte……

考虑一下在适合的时候抛出 EOFException

现在基本可以认为，底层读写部分快写完了

就剩下测试 Writer 了

现在我修复了 Writer 里关于 bitwise operation 的 bug，程序的底层输入输出架构现在可用了。

程序尤其注重抽象性，连测试都是平台不直接相关的，方便移植到各种各样的底层来使用。

不像 Parser 的函数式接口可以有方便的 then，这里做不到，因为既要能读又要能写，不可能单独在读的时候转化为另一种数据类型。
其实也不是不可以，但那样的收益就太低了，要同时写 from 和 to