迫不及待地想把那个高大上的库打得落花流水了，我是指 API 和实现优雅性上。
马上就没有它支持我不支持的功能了，草（不过还是觉得好无聊啊， multi param argument 不知到底有何意义…… 很好用么）
真希望以后发布了会成为那个库对比名单上不敢写的东西啊，毕竟已经多了这么多功能了…… （虽然我还是觉得那些功能纯属鸡肋）
马上就没有它支持我不支持的功能了，草（不过还是觉得好无聊啊， multi param argument 不知到底有何意义…… 很好用么）
真希望以后发布了会成为那个库对比名单上不敢写的东西啊，毕竟已经多了这么多功能了…… （虽然我还是觉得那些功能纯属鸡肋）
唉，果然还是工程上的事人多些吧。 Kotlin 的解析组合子库，除了 ParserKt 外只用一两个，太无聊了…… 算上 JVM Java Scala 的估计也不多。
现在的 JVM 程序员怎么思想都这么封闭…… parser generator 倒是见过不少
现在的 JVM 程序员怎么思想都这么封闭…… parser generator 倒是见过不少
https://github.com/taocpp/PEGTL 草，开始我点进去的时候还害怕这个库非常易读，没想到还是传统 C++……
就是
struct sign: one<'+', '-'> {};
struct integer: seq<opt<sign>, digit> {}; 就是
val sign = elementIn('+','-').toDefault('+').convert { it == '-' }
val signDigit = Seq(sign, digit).convert { if (e1) -digit else digit } 啦。GitHub
GitHub - taocpp/PEGTL: Parsing Expression Grammar Template Library
Parsing Expression Grammar Template Library. Contribute to taocpp/PEGTL development by creating an account on GitHub.
为什么这个道理这么简单，但是明明是大佬的人却不懂…… 我以为高等的 C++ 程序员就会明白，命名不是越短越好、定义不是越长越好；可是为什么我看过那么多框架，懂得精炼的人却那么少。
太聪明了…… 聪明反被聪明误么
parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧……
不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
太聪明了…… 聪明反被聪明误么
parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧……
不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
duangsuse::Echo
为什么这个道理这么简单，但是明明是大佬的人却不懂…… 我以为高等的 C++ 程序员就会明白，命名不是越短越好、定义不是越长越好；可是为什么我看过那么多框架，懂得精炼的人却那么少。 太聪明了…… 聪明反被聪明误么 parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧…… 不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
其实都不是，是我太不懂遵守语言标准代码风格约束了……
为了以更明确的语义解决领域的问题，我不惜牺牲标准的风格，只为追求易读性和无歧义，草。
为了以更明确的语义解决领域的问题，我不惜牺牲标准的风格，只为追求易读性和无歧义，草。
duangsuse::Echo
https://github.com/taocpp/PEGTL 草，开始我点进去的时候还害怕这个库非常易读，没想到还是传统 C++…… struct sign: one<'+', '-'> {}; struct integer: seq<opt<sign>, digit> {}; 就是 val sign = elementIn('+','-').toDefault('+').convert { it == '-' } val signDigit = Seq(sign, digit).convert { if…
其实仔细想想，这行凭能力说话，大佬永远是不会差的。
与其把心思放在猜测每个接口程序员乃至用户会如何使用，还不如好好研究下算法和数学思想，我是智商不够用，被迫选择干这种低劣愚蠢的“优化”的。
既然这么简单都没人用，显然是别人已经知道了也抛弃了，库的作者应该是为算法、技巧和自己的名誉服务，怎么可能应该是给使用它的东西服务？ 看来我想得太多
与其把心思放在猜测每个接口程序员乃至用户会如何使用，还不如好好研究下算法和数学思想，我是智商不够用，被迫选择干这种低劣愚蠢的“优化”的。
既然这么简单都没人用，显然是别人已经知道了也抛弃了，库的作者应该是为算法、技巧和自己的名誉服务，怎么可能应该是给使用它的东西服务？ 看来我想得太多
duangsuse::Echo
4.3K 了
草…… 说起来我今天又靠整日坐+熬夜 把 subcommand 写出来了…… 其实实现思路不咋高大上，而且 可能有缺点。
这样即便能比上另外的库，对我而言又有什么意义……
这样即便能比上另外的库，对我而言又有什么意义……
https://github.com/duangsuse/kamet-dse/commit/1678087f9fe2733d37b826903507f0077aeabc5e
乱代码辣眼睛，重构代码能减少程序对眼睛的危害，什么时候重构都不为晚
乱代码辣眼睛，重构代码能减少程序对眼睛的危害，什么时候重构都不为晚
GitHub
ArgParser: Cleanup code · duangsuse/kamet-dse@1678087
duangsuse's rewrite for Mivik/kamet LLVM compiler. Contribute to duangsuse/kamet-dse development by creating an account on GitHub.
Forwarded from 层叠 - The Cascading
Telegram
荔枝木
啊这……
Forwarded from dnaugsuz
嘛，吃早饭的时候想到 ParserKt 跳过 Expr 里的 /* 注释的问题，说是不可能完成(因为要 lookahead)，发现是我错怪它了……
它读取 Expr 链用的是 InfixPattern ，而这个 Pattern 接收的是
它读取 Expr 链用的是 InfixPattern ，而这个 Pattern 接收的是
Pattern<Char, InfixOp<T>> 所以只要给 Trie 外面包层 Piped.decide， 然后如果是 /* 就返回一个跳到 */ 的解析器，否则 always(op) ，实际上是可以实现，只不过那个跳到 */ 的Pattern超级难写，而且这个做法超级鸡肋而已（只为区别除号和注释就得在 Trie 外再包一层…… 还不如允许 lookahead 开销小呢）Forwarded from dnaugsuz
不过我是真打算抛弃老的 ParserKt 了…… 看起来 crossinline 更有魅力一些，而且老版的代码虽然不冗余但也有很多比较鸡肋的功能，对实践的意义有疑问，而且新版一样支持 Trie,NumUnit,Lexical,Layout 这样复杂的 pattern 和 unparse ，只不过就不能写
!element('x') 这种利用 OOP PatternWrapper 的特性了。