唉，果然还是工程上的事人多些吧。 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 的特性了。