我在想，其实递归下降法本身就很简单了，所以不一定必须弄太多Feeder什么的…… 还有『随机』MarkReset
很多文法都是LL(1)的，搞这么多纯属多余（虽然也不一定没用）

既然需要Mark/reset的时候很少，不如就只针对Peek进行扩展，让它能够随便(惰性地)支持MarkReset，不为那种File input的情况考虑了（反正PeekStream也足够高效了）
然后 SourceLocation 不一定非得Mixin，之前在ParserKt算行号的代码测试过可以拿到 SourceLocation 对象里作为它上面的方法，然后弄个（当然这次不会有所谓『Feeder架构』的屑问题了，只有一种Feeder）SourceLocPeekStream 把它包装起来，也不再同时兼容 CR, LF, CRLF，世界上哪有同时采用两种换行符的文字？Kotlin 支持 LF 或者 CRLF…… 那还是抽象出来让用户实现吧


什么镇静解析策略啊，就不要实现了，当然不是说递归下降实现不了，而是完全没必要实现 — GHC, Nashorn, Lua, Ruby 等主流语言/实现都没支持这种解析技术
而支持所谓『镇静策略』的Kotlin，效果和 GCC 一样不咋地，强迫自己吃屎一样，代码稍微错一点所谓的『镇静』就会弄出一大堆错误，根本不智能，真不知道这东西是设计过来干什么的。
『跳过』只会弄出更多岔子、『补上』你又有什么好补的？括号看起来是漏了可以补吗？除非一些显而易见的情况，当然我不是给IDE写解析器，所以不用支持完美的容错。

然后这次又是一个挂羊头卖狗肉的项目：Calc.kt，名字上是计算器；其实是支持Lambda Calculus的计算器，和一个解析器编写框架。

为了修复我花了那么大力气弄来的算法，我又和 Nashorn 测试了一下，暂时只看性能：

== summary ==
systemStack: 10 reports
of: 130.369micros, 27.851micros, 22.139micros, 24.31micros, 20.414micros, 21.36micros, 17.997micros, 19.12micros, 18.467micros, 19.574micros
min=17.997micros, max=130.369micros, mean=32.1601micros

AdtStack: 10 reports
of: 31.316551ms, 5.489379ms, 4.334858ms, 4.266494ms, 3.904404ms, 3.900235ms, 6.83763ms, 3.424587ms, 3.8487ms, 3.460497ms
min=3.424587ms, max=31.316551ms, mean=7.0783335ms

Nashorn JS: 10 reports
of: 342.638024ms, 15.991645ms, 18.379428ms, 11.238317ms, 9.294446ms, 7.796577ms, 7.543127ms, 7.239315ms, 6.986252ms, 5.68631ms
min=5.68631ms, max=342.638024ms, mean=43.2793441ms

—为什么 systemStack 那么快？因为我把测试逻辑都注释掉了…… 打住。

艹，我一个也没写对…… 全错了，我真的不敢相信
测试输入包含 5 个 token，也就是说是：

492 /  5912  / 40 * 2485 -  7688 * 94 *  26175  *  806  - 228  *  51 +  97779

这样。

Launch systemStack 29903450318121
= 0
Finish systemStack in 341.87micros
Launch AdtStack 29903455998170
= 132609292
Finish AdtStack in 1.790674ms
Launch Nashorn JS 29903458052996
= -1.524697469698283E13
Finish Nashorn JS in 334.887835ms

我找 Ruby 问了也是一个结果，这 TMD 怎么可能？
为了保证不是优先级的问题，我决定手工结合一下看看：

(( (((492 /  5912)  / 40) * 2485) -  (((7688 * 94) *  26175)  *  806) )  - (228  *  51) ) +  97779

=> -15246247231449

这么说我的解析算法写错了？

/usr/lib/jvm/java-1.8.0/bin/java... CalcMain
(( (((492 /  5912)  / 40) * 2485) -  (((7688 * 94) *  26175)  *  806) )  - (228  *  51) ) +  97779

^D
886669351
emmm...

Σ 492 /  5912  / 40 * 2485 -  7688 * 94 *  26175  *  806  - 228  *  51 +  97779
 = Just ((((((492.0 / 5912.0) / 40.0) * 2485.0) - (((7688.0 * 94.0) * 26175.0) * 806.0)) - (228.0 * 51.0)) + 97779.0)
 = -1.524624723144383e13

生艹，是真的了，是Calc自己都有问题
GNU Bc 和我之前写的 BinOps 都正常

((((((492 / 5912) / 40) * 2485) - (((7688 * 94) * 26175) * 806)) - (228 * 51)) + 97779)

简直奇了，它是怎么弄出886669351这个结果的？？？ 🌚🌝？？？

好像是算错了。
((7688 * 94) * 26175)
Ruby 得 18915939600

irb(main):001:0> ((7688 * 94) * 26175) 

=> 18915939600

它得 1736070416

((7688 * 94) * 26175) 
^D

1736070416

well done.

问： 722672.times(26175) 是多少？
Kotlin: 722672.times(26175) == 1736070416
Ruby: 722672*26175 => 18915939600

？？？原来整数误差也可以跨语言了？？？

艹，才想起来很多脚本语言里数值类型混乱不堪；Ruby 曾经还分过 Fixnum 和 Bignum，肯定是这些在诬陷正直的 JVM。

只好解析成 AST 的形式由我自己来鉴定真伪了……

这个时候就需要鼓吹我们正直的 JVM、CLR、C++，不与一些辣鸡脚本语言同流合污、随手胡乱对待数值类型。
明明写着看着是 1，其实是 1.0 的这种语言和辣鸡 JavaScript 是没有灵魂上的区别的。

……可惜正直的语言还不如 Python3、PHP 火，可惜啊可惜

typealias Atom = Int

这时候就体现你用 Typealias 的一个好处，就是想用用、不想用随时换，不会找不到该改哪

算法请参照：
https://github.com/duangsuse-valid-projects/three-kt-files/blob/master/src/commonMain/kotlin/Calc.kt#L103

跑分实现在：
https://github.com/duangsuse-valid-projects/three-kt-files/blob/master/src/jvmMain/kotlin/BasicBench.kt (lib)
https://github.com/duangsuse-valid-projects/three-kt-files/blob/master/src/jvmMain/kotlin/CalcBench.kt

#Telegram #dev 挺好啊，比那些不用框架的强多了

其实啥时候 Harray Ying 为什么不去学学范畴论呢…… 最近偏工程的事情很多，没时间看这篇文章了……

Recently, I have been working on Abstract Algebra which has derived category theory and exposes its strong relation with computer science.
其实就是范畴论的…… 看到 Log 我第一时间想到的是对数(logarithm)……

难怪，代数的抽象
为了确认 title 里 Log 的含义其实我还是忍不住打开看了，那就顺便翻译一下。

Abstract Algebra Learning Log - Preliminaries by Harry Yin
《抽象代数》学习笔记 — 预章
—
Recently, I have been working on Abstract Algebra which has derived category theory and exposes its strong relation with computer science.
最近我在学习抽象代数，自它派生出了范畴论，它与计算机科学有很大联系。
—
Brief Introduction
简要引言
—
All these learning logs will be based on one online and free textbook (2019 Version), naming Abstract Algebra which is licensed under the GNU FDL.
This learning log is basically in two parts, one is my own understandings or complementions to some of the parts, another part is my own answers to part of the Exercises section in the end of the chapter. And succeeding learning logs will mainly based on this form too.
First part may contain works in the textbook itself, therefore, this series of posts is licensed under the GNU FDL either.
这些笔记都是基于一个免费的网上教材(2019版)，它以 GNU FDL 开源，名字叫《抽象代数》Abstract Algebra。
我把笔记大致分成了两部分，一部分是我自己的理解和补充，另一部分则是我对书中节末练习的解答。
后继的学习笔记也会基本保持这个形式。
第一部分可能包含教材里既有的内容，所以，这一系列文章也以 GNU FDL 许可证发布。
—
Understandings and complementions to textbook
部分一，对教材内容的理解和补充
—
Page 6, Proof of De Mogran's Laws
P6，De Mogran 定律的证明
—
1. $(A\cup{B})' = (A'\cap{B'})$
We define two statements, $p$ and $q$, representing $x\in{A}$ and $x\in{B}$ respectively.
statement $x\in{(A\cup{B})}'
\Leftrightarrow{\neg{ (p\lor{q}) }}
\Leftrightarrow{ (\neg{p}\land{\neg{q}}) }
\Leftrightarrow{x\in{ (A'\cup{B'}) }}.
$ (The relation between $\neg{ (p\lor{q}) }$ and $(\neg{p}\land{\neg{q}})$ can be deduced by simply enumerating through all the possible values of $p$ and $q$, e.g. $true$ or $false$ for statements).

Thus, $\forall{x}\in{(A\cup{B})'} \rArr{ x\in{ (A'\cap{B'}) } }
\rArr{ (A\cup{B})' } \supset{ A'\cap{B'} }$. Conversely, we can prove $(A\cup{B})'\subset{A'\cap{B'}}$.
{— 注：原文使用 Emacs org mode 排版，这里 TeX 上稍有修改，原文采用 GNU FDL 许可证 —}

…… 算了这么多数学公式，我干脆用 TeX 排版了发吧