好，那我说的已经完成了，我干别的去吧…… #Java #PL #PLT #CS

第一次玩 Kotlin/Java 混合开发
我也不是很确定是不是没有 bug，但我尽力了，这是我第二次写 Feeder（修好了第一次的不良实践，也推掉了一些特性）

理论上基于 Feeder 的解析器不应该使用子类的，不过我这次上了个『不良实践』…… 不过一切都好，二元操作链解析正常

我自己都觉得很奇怪，即便这不是什么稀奇的事情（函数式风格的解析器嘛……）

既然委托了 Kotlin，显然是不可能完全不用 stdlib.jar 的，不过我们可以用 proguard

这次的 Feeder 虽然支持（实验性地）MarkReset.Multi，也就是说，它能够用来给嵌套的 Branch 解析器喂东西，此外，它还使用了可以 Clone 的 Iterator（我是参考了 Haskell 的一切皆『复制』方案）
不过它不支持 Stream，也就是说，不能拿来做 REPL（所以你们看到，我是用 Scanner，而且 Java 的 lang.Character.isWhitespace 不知道哪个分支有毛病，不能自动跳过 '\n' 换行符，气死了
至于为什么不支持，其实支持起来也未必就非常复杂（就是一堆 buffer 有点绕而已）
是因为我不需要它来写 REPL……

就是这样了，那么告一段落，祝你们玩得开心，喵。 🐱
代码过会我会发上 GitHub

目前支持的中缀操作符

最后还是有点 bug，不过也有重构的部分

『我们保证以后不会往肉里打水了，我们欢迎你们来监督……』 — 《四十一炮》

暂时不发 GitHub 了，直接发文件算了 #Share #code #Java #Kotlin

其实，Lexer 是 LL-1（只用向前判断一个字符）的，但是 Parser 严格上来说它不能扩展自 Lexer
Parser 实际上也只是 Feeder<Character>，它的输入流支持 lookahead-1，可是那是字符层面的 lookahead，而 Parser 实际上只解析 token()

Lexer 的 token() 导致了看起来也该是基于 Feeder<Token> 的 Parser 实际上却是基于随机 mark()/reset()，你不得不在每次匹配失败的时候重置输入，免得下一次 token() 返回不同的结果（我们的子解析器不能保证，在 token() 一次的情况下总是可以成功，所以一旦遇到未预期的 token()，不得不『消耗』掉它，即便调用自己的解析器不希望那么做）

这种情况，其实应该使用解析组合子框架（当然过会我会弄一个的，早想好了）

所以我打算弄一个 StreamFeeder 和一个给 Java 的 Sequence（Sequence.OfProducer, 如果用 Kotlin 会缩减无数无聊的代码，可是我不知道 Kotlin 的 Sequence 有没有太大的体积问题……）
这样，我们的 Parser: StreamFeeder<Token> 里

constructor(String file, CharSequence code): super(file, Sequence(Lexer(file, code)::token))

再次强调，Feeder 本该是给组合函数式解析器喂 item 的（它就不应该 open），我会弄个 Delegate 把它的所有方法移到 AbstractFeeded 里
不过这样也就没法搞定 onItem, onEnd 的问题了……

剩下的部分我会继续使用 Kotlin/Java 混合编程，面向库使用者的部分我会用 Java，核心的部分我使用 Kotlin（真希望 Kotlin 不会往上加个几十兆……）

没什么目标，也只好信手去做……
我想把 Dokuss 完成，可是 Parser 也要写…… 而且 Dokuss 剩下的一个 Nat16, Nat8 的 ZExt （zero-extension）有点不好弄
zext 是因为 Nat16 其实是 kotlin.Short 实现的，它把高位的比特当作 sign 解释，.toInt() 的时候就会错误解释一个比特的信息
我们要先 toInt()，然后移位 bitwise or 操作把这个比特加回来
可是它不好测试

proguard -keep 'public class calc.inst.Main { public static void main(java.lang.String[]); }'
-injars calc.jar -out calc_out.jar
-libraryjars '/usr/lib/jvm/java-9/jmods/java.base.jmod(!**.jar;!module-info.class)'
-dontobfuscate -dontwarn
以后是 48K，我看看换成 Kotlin 的 collection 会不会加体积

开始试着习惯写测试了 #Java #Kotlin #dev

我现在才明白王垠的看法是片面的，像是这种情况，你标 return 是不对，这不是表达式的风格

我实在不敢再去想…… Linus 不是有一句话说，编程的两种方式一是认真思考，二是在无数个机器上测试，那我就多写点测试吧，真 TMD 太困难了！

最后一个 ++ 很是难理解，我都不知道自己是怎么写出来的…… 又搞不懂了，emm

Trace 还是不好写，不写了 #Algorithm #Kotlin

本来数学不好，还要写这个自己都不知道是为什么要那么写的东西
何况刚才我写的链表也缺了点东西，比如 insert 操作…… 它应该可以加在 iterator 上面
但是单就这个数据结构的实现上来看，我觉得还有很多应该思考建模方式的东西

既然本频道之前的东西都没上 LICENSE，这次的代码也不上了，妮妮萌萌系爱抄抄吧，只要你们会就行了。

一些代码留着下次可以继续测试和复用，比如 Feeder
StreamFeeder 有点累了，没写出来（即便是写出来也不需要太大力气，而且可以继续写方便复用的解析器框架

它不依赖我写的 Linked.List，话说 Linked.List 把 ProGuard 的 partial evulation 都给弄炸了，还说找不到 calc.Linked.Cons 和 calc.Slice 的公共超类？莫名其妙，即便 Cons 是属于 sealed class 的 data class。

#China #dev 是浩哥！ #Linux #sysadmin #life

黑客是为了挑战最有难度的技术，就像Unix那样，像Linux那样，他们主要是为了提供更好更牛的东西，他们不破解软件，他们用自己的能力重写一套更牛逼的软件。他们还像telegram一样，支持1.5GB的文件 ，支持20万人的群，无限人数的channel，以及足够开放的平台……这才是真正的hacker精神

#Python 有这种工程师，我也是服了，也是 NB。 #Low #China

#Kotlin 是好事，你看那 Deprecated 本来就应该换了（而且 Kotlin 的 annotation class kotlin.Depreacted 还带了 IDE 自动替换（比如，val T.isUserAMonkey get() = … 能够换成 .isMonkeyUser 自动的；

至于 Null safety (Nullability) 更是 Kotlin 比 #Java 化腐朽为神奇的地方（当然，in/out 型变性声明而不是 ?super/?extends 类型上下限界也是一个优秀之处），这实在可以说是 Kotlin 最骄傲的地方之一。

它既然觉得 str: String?, 你 str!! 一下就可以拿到 kotlin.String! 了(也可以用 ?. 安全 Null 传导)，不过如果真的是 null 引用的话，就会抛出 KotlinNullPointerException


val files: Array<File>? = …
files.forEach { f -> f.close() } // Unsafe use of a nullable receiver of type Array<File!>?
(fn as (String) -> *)(json["user_nickname"]) // Type mismatch: inferred type is String? but String was expected