这么多天没一个 commit 的原因是在整这玩意儿：
https://github.com/Rachel030219/YibanSubmission
是我校每日易班健康打卡的小工具，理论上订阅频道的各位用不上，但是如果碰巧各位打卡流程也是「易班→易班校本化→每日健康打卡」，那么这个小工具在简单地修改后应当也能派上用场。
我认识的几位学长的支持与贡献是这个应用的基础，特此感谢。
值得一提的是，这是我写过网络请求最乱最脏最重、UI 最「缝合怪」以及含有最多动画的应用。

#china #android #design

今日帆吐槽——这些牛皮藓般的icon，都是谁想出来的

#Python #db #i18n https://t.me/py_zh_real/13892 jieba,elasticsearch,bigram,opencc

#PLT #ce #china #recommended #project #csharp

补充一下我真实的观点：绝句的新特性很多，但核心特性也不过七八个而已，我最看重的就是逗号表示法（囊括了逗句简写和「为」「其中」关键字）、逻辑算符否定、记法和类型推导，此外还有多语种API命名互译之类工具性的东西，所谓「人称文法」更多是一个提纲性、辅助学习者记忆的东西，本身无关键意义。

但是，其实我最看重的缩进语义「逗号表示法」，也是最难被抄走的——目前我自己也还在实验中，要设计的边角情况很多，如果真的有人能写出来，我只能是崇敬大于嫉妒了，虽然我明白自己迟早会实现它。

之前的『文言编程语言』，我是一点都不慌张，因为它就是一位算法系前端倡导下一群前端共建的游乐园，不重视真正的表现力更惘谈 layout(缩进)等实用的学院派元素，无论在语法还是语言结构都不足以涉足应用编程，现在也一样。
不过也必须注意了……

不过呢，我发这么多不是因为嫉妒，只是因为心态有点摇摆；其实，中文的计算器我也写过，而且稍稍扩充下就可以兼容这个项目目前的示例🌝 但我也该警醒了

另外，(==) 翻译成「是」，其实是非常普遍的翻译方法，只有两成在用「等于」的直译，这层面没什么好推陈出新的。

没有人是可以永远站在相对较高的位置的，除非是一个比你小又比你强的大佬，那你就永远无法超过他了|･ω･｀)😂

https://t.me/py_zh_real/13942 #Python #i18n #code #db

https://github.com/terrajobst/minsk#browsing-the-code #csharp #PLT (其亲项目, inspiration 来源)居然专门注册了 minsk-compiler.net 这个域名，也是够 rich... 不过 C# 程序员到底是很有心

#recommend #tools 合并翻译软件吗

https://github.com/CASC-Lang/CASC/blob/master/src/CASC/CodeParser/Syntax/Lexer.cs#L147 好吧，看来我的确要吃土了（
看看能不能重写下。

https://github.com/CASC-Lang/CASC
我会一如往常在频道里进行项目结构分析，然后用与 C# 相对的 Java （竟然不是 Kotlin... ）进行一些并行的重写工作。
之所以用 #Java 写这样富于技巧的 #CE 编译器 程序，是因为我想常常新口味了…… 一些原来 Kotlin 里有的我也用 TypeScript 重写过

原项目是一个“能编译繁简体中文、甚至英语”的编译器，目标是对简体程序员可用。
ChAoS_UnItY (Chaos Unity) 开发，由 C# minisk-compiler.net 起意，后者是一个通俗的基础教程示范，也囊括对 IDE 等语言工具 暴露 parser 、 type checker 等“更远的”工作的示范。 #recommended

程式碼範例

一加二十一是二十二 == True
(1 + 9 - 7) 是 (一 加 九 減 七)
1 + 九 減 7

这个没啥，相关知识： 算符链 InfixPattern/«Lua设计与实现» 相关章节; 中文数值 NumUnit/han() #learn

https://github.com/CASC-Lang/CASC/releases/tag/v0.0.1 看了以后我 🤔了很久，发现连 () 都是“运算符”而且还是 "TP"(tech. preview) 后我头疼了(显然我必须改掉这些设计)
而且它的文档表达的 OUA(Operator Unacceptable, 不接受数学形式) 让我也晕了一下

build 没什么好说的, azure CI + dotnet SDK .NET 5.0, publish build artifacts, NUnit tests
其 build.cmd 就是 dotnet build src/+test-proj/

那么看下关键点——词法、语法、计算与类型转换、作用域和函数调用。

Lexer.cs: Whitespace char.IsWhiteSpace (为 " \t\n\r" 优化), Identifier/Keyword char.IsLetter,
整体是 _position, _kind:SyntaxKind 实现的，有趣的是 identifier text 是靠算 span 再 slice 取的，本身倾向流式 Peek(offset), Current, LookAhead=Peek(1), '\u0000' EOF 但不完全
第一个 readonly List<char> 无使用
写的是： 加 減 乘 除 點 開 閉 正 負 且 或 反(非,!) 是 不(是,!=) 赋(=)
开闭括号的我感觉有点奇怪。

加正+減負-
乘*除/
(){}
且 &&
或 ||
反!
!= 不是
是==
賦=

命名都像 SyntaxKind.BangEqualsToken(!=) .StarToken(*) .SlashToken(/) 这样
其中 ==, &&, ||, != 的需消歧义，但没有 lookahead 而是以状态机区分、「不是」「反」「赋」 都是别名

0123456789零一二三四五六七八九
壹貳參肆伍陆柒捌玖拾十百千萬億
靠外置 ReadNumberToken(); 读数
另外都做了 ReportBadCharacter 的错误记录工作
以上皆返回 SyntaxToken ，试用 SyntaxFacts.GetText 拿内文，如果则用当前 span 取 substring 。

Parser.cs:
CompilationUnit, Stmt, BlockStmt, VariableDeclaration, ExprStmt, VariableDeclaration, Expr, BlockStmt, Stmt, ExprStmt, Expr, Expr, AssignmentExpr, AssignmentExpr, AssignmentExpr, BinaryExpr, BinaryExpr, BinaryExpr, PrimaryExpr, BinaryExpr, PrimaryExpr, ParenthesizedExpr, BooleanExpr, NumberExpr, NameExpr, NumberExpr, ParenthesizedExpr, Expr, BooleanExpr, NameExpr

其中带 Binding(他没解释但估计是作用域上下文，但我很好奇为什么要给每个 Node 键一个 BoundedXXX) 支持的：
BlockStatement, ExpressionStatement, VariableDeclaration
LiteralExpression, VariableExpression, AssignmentExpression, UnaryExpression, BinaryExpression

感觉挺无聊的，还是开始重写吧 🤐
不对，把 Text/Stream, Binding, ChineseParser.cs 上的痛点先说下才能继续
架构的问题太大了，尤其是 Original/WithBinding AST, 这个绝对要想办法削掉

其实 Java 的基础面向对象结构绝对不比 C#，我不用 Lombok 但会争取 Kotlin 移植可能，作为休闲弄几天吧。

...我觉得作者是真的没有这种 Do not Repeat Yourself 的意识，老实说， getZHText(TokenKind) 就得 Iterable<String> 的用处我觉得蛮奇怪的——这不是 parser 需要识别，基本只 toString() 用，那么为什么需要“全部”可能的设计关键字呢？目前我只在 Unit Test 里找到了用例，看来作者是不重视程序简洁性的，比较严重(之前协作 Mivik/kamet 的时候怎么可能看到这种大 switch-case 代码，何况是在 parse 完的后期处理里)。

Qv2ray 主项目 Archive 一小时

以纪念所有参与开源项目开发但未获尊重的开发者