9:57:35
简洁就是把自然语言变成数学，首先它就不是 Kotlin 的选择
性能是要看 profile 的，而且我相信足够的抽象反而可以在未来带来更好的性能
超高校级的门卫 2020-03-12 19:57:48
别人甚至会讨厌你提供surrounded by这样的组合子
duangsuse 2020-03-12 19:58:23
ParserKt 也有一门 "bnf" DSL 已经设计，还没时间实现
超高校级的门卫 2020-03-12 19:58:42
你如果能把性能优化作为重点，那也是可以的。parsec唯一的优点是类型安全，而其上的优化有大量文章可做
超高校级的门卫 2020-03-12 20:01:38
parsec没有优化的话，中型的parser，比如json这些比LR/LL codegen慢个几千倍不是很难
超高校级的门卫 2020-03-12 20:02:14
常见编程语言的parsing就要更慢了
超高校级的门卫 2020-03-12 20:03:20
https://github.com/lihaoyi/fastparse/blob/master/README.md
超高校级的门卫 2020-03-12 20:03:36
你可以先比一下
超高校级的门卫 2020-03-12 20:03:44
找出你有哪些优点
超高校级的门卫 2020-03-12 20:03:58
他作为一个标杆，是比较菜的
收藏于昨天 群-迂腐的学院派编译技术
#qq #PLT
简洁就是把自然语言变成数学，首先它就不是 Kotlin 的选择
性能是要看 profile 的，而且我相信足够的抽象反而可以在未来带来更好的性能
超高校级的门卫 2020-03-12 19:57:48
别人甚至会讨厌你提供surrounded by这样的组合子
duangsuse 2020-03-12 19:58:23
ParserKt 也有一门 "bnf" DSL 已经设计，还没时间实现
超高校级的门卫 2020-03-12 19:58:42
你如果能把性能优化作为重点，那也是可以的。parsec唯一的优点是类型安全，而其上的优化有大量文章可做
超高校级的门卫 2020-03-12 20:01:38
parsec没有优化的话，中型的parser，比如json这些比LR/LL codegen慢个几千倍不是很难
超高校级的门卫 2020-03-12 20:02:14
常见编程语言的parsing就要更慢了
超高校级的门卫 2020-03-12 20:03:20
https://github.com/lihaoyi/fastparse/blob/master/README.md
超高校级的门卫 2020-03-12 20:03:36
你可以先比一下
超高校级的门卫 2020-03-12 20:03:44
找出你有哪些优点
超高校级的门卫 2020-03-12 20:03:58
他作为一个标杆，是比较菜的
收藏于昨天 群-迂腐的学院派编译技术
#qq #PLT
GitHub
lihaoyi/fastparse
Writing Fast Parsers Fast in Scala. Contribute to lihaoyi/fastparse development by creating an account on GitHub.
超高校级的门卫 2020-03-12 20:04:52
你能作为"有特色"的框架去beat标杆的某些方面，或者成为这个标杆的闭包
duangsuse 2020-03-12 20:07:22
@超高校级的门卫 我也去看过不少同类框架。
他们也的确是“相差无几”，但就我个人来看，他们唯一差的就是，太聪明了…… 太学术了……
比如 https://github.com/h0tk3y/better-parse，它是用了很多很厉害的技术(e.g. codegen)，但不是很工程，而且容易被滥用一些 combinator 的 infix notation
不忘掉 BNF 那套繁琐的 terminal / non-terminal 术语，不摒弃以往 scannerless parser框架 的实现模式，怎么可能弄出 ParserKt 这种泛向的框架的说(≧ω≦)
duangsuse 2020-03-12 20:08:21
下次重构后去跑分！现在还在各种优化接口……
超高校级的门卫 2020-03-12 20:09:26
bnf和scannerless不冲突
超高校级的门卫 2020-03-12 20:09:38
你的泛向在哪里
duangsuse 2020-03-12 20:09:46
泛型解析。
超高校级的门卫 2020-03-12 20:10:09
你举例子
duangsuse 2020-03-12 20:10:14
// Generic parsing for [1, a, b] where (b > a) val ints = Seq(::IntTuple, item(1), *Contextual(item<Int>()) { i -> satisfy<Int> { it > i } }.flatten().items() ) ints.rebuild(1,2,3) //[1, 2, 3] ints.rebuild(1,2,1) //notParsed i.rebuild(1,0,1) //[1, 0, 1]
超高校级的门卫 2020-03-12 20:11:47
哪里泛型了？
duangsuse 2020-03-12 20:12:00
https://github.com/ParserKt/ParserKt/blob/master/README.md#introduction
就是这里的代码示例
超高校级的门卫 2020-03-12 20:12:02
这是parsec都能做到的
超高校级的门卫 2020-03-12 20:12:10
你无非做了一个constraint
duangsuse 2020-03-12 20:12:13
输入是 Int
超高校级的门卫 2020-03-12 20:12:25
这不是什么问题
超高校级的门卫 2020-03-12 20:12:36
haskell parsec是母版
超高校级的门卫 2020-03-12 20:12:44
token是泛型的
duangsuse 2020-03-12 20:13:01
可是我见过所有的 Kotlin parserc 都不能 (＾ν＾)
duangsuse 2020-03-12 20:13:23
而且 Haskell 的 parserc 谈不了性能
超高校级的门卫 2020-03-12 20:13:53
haskell是一个相当快速的语言，你应该多做benchmark
duangsuse 2020-03-12 20:14:08
到处 shallow copy 的 product value mapping 是很难做到服务端的性能要求的
duangsuse 2020-03-12 20:14:43
GHC Haskell 的性能往往要靠特别的优化
超高校级的门卫 2020-03-12 20:14:49
我一直觉得发生shallow copy的是非pure语言使用list的时候
超高校级的门卫 2020-03-12 20:14:59
而haskell整好避免这一点
duangsuse 2020-03-12 20:15:51
而且 Kotlin 是内部支持 imperative 的语言呢，Haskell 是另外的世界
超高校级的门卫 2020-03-12 20:16:21
如果事实如此，那确实是挺不错的。@定理证明器 当年好像没把我的库移植过去完，不然也是个token type可变的
duangsuse 2020-03-12 20:17:31
不过这个里面有不少点子都是我自己想出来的比如 Feed/Pattern (可 read 可 show) 还有 clam, clamWhile, alsoDo, stateAs 什么的
超高校级的门卫 2020-03-12 20:17:37
不过我当年第一个parsing尝试就是在非传统token的type上做的，写完就有人说太naive。我认为不太容易获得认同
超高校级的门卫 2020-03-12 20:17:55
别人看会觉得挺复杂的
超高校级的门卫 2020-03-12 20:18:30
我以前也搞很多新东西，后面发现无非是一个user define的parsec函数
超高校级的门卫 2020-03-12 20:18:57
我对我以前的评价就是，做出了parsec的左递归支持，牛逼。别的，垃圾，闭门造车。
duangsuse 2020-03-12 20:20:58
From big power comes big responsibility比如说，PKT 里 SurroundBy(clamly(parens), stringFor(anyChar)) 你可以在错误提示里获得开括号的 sourceLoc （前提是 input 必须包含 ExpectClose 实例的状态）而手写是这种做法的…… “无结构”写法ANTLR？它做不到，因为它不知道什么是 paired Pattern
超高校级的门卫 2020-03-12 20:23:09
有意思，你可以讲一些你这个开括号错误提示比antlr强在哪儿
超高校级的门卫 2020-03-12 20:23:43
(xxx你会提示(的loc而不是最后一个x的loc?
duangsuse 2020-03-12 20:25:15
不过 SatisfyPattern.clam 和 Pattetn.clamWhile 也的确是受启发的
就是编译原理所谓的“镇静解析策略”
ParserKt 里的 Pattern, read 成功就是 T, 失败了就是 null (notParsed)
所以，clamWhile(pat, defaultValue, messager) 可以提供一个可定制的出错提示
我尽可能把 parserc 在语言可以表达的逻辑的集成方面的优势用到了…… 就那样吧
超高校级的门卫 2020-03-12 20:25:49
这是user define的行为
超高校级的门卫 2020-03-12 20:26:13
用户会选择自己写一个这个功能，而不是记忆你的api
duangsuse 2020-03-12 20:26:57
就像 Java 8 的 obj.someCall()它的 NPE 不会提示 null 的东西是 obj。ParserKt 可以在找不到闭括号的前提下显示expecting ')' (from file:line:column)
超高校级的门卫 2020-03-12 20:28:04
你确定antlr做不到？我认为LL和LR都应该有这个能力，除非parser的失败是在内部的rule
超高校级的门卫 2020-03-12 20:28:29
而内部rule失败，报出外部还没遇到的错误也不太合理
duangsuse 2020-03-12 20:28:42
不过这个错误提示也的确是可定制的相关代码在这里：https://github.com/ParserKt/ParserKt/blob/master/parserkt-ext/src/commonMain/kotlin/org/parserkt/pat/ext/MiscHelper.kt#L48
超高校级的门卫 2020-03-12 20:29:04
这哪个parsec都都可定制
duangsuse 2020-03-12 20:29:16
不确定，但是它不会知道“() 是配对的两个东西”
超高校级的门卫 2020-03-12 20:29:17
这你还要说只有你可定制吗？
duangsuse 2020-03-12 20:29:47
不是只有 ParserKt 可定制，是只有它定制最方便
超高校级的门卫 2020-03-12 20:30:33
这是user define的东西，一定存在kotlin edsl能够对任何parsec后端work
duangsuse 2020-03-12 20:30:58

超高校级的门卫 2020-03-12 20:31:13
你定制方便没有意义，因为用户本来就不期望库里面做一些特殊use case的事情
duangsuse 2020-03-12 20:32:03
谁知道呢？(๑ゝω╹๑)
超高校级的门卫 2020-03-12 20:33:16
像antlr这种次级parser生成器，以及现在的可用parser生成器，都可以正常的报出)没match。至于说要提示没match哪个(，这个需求不具有说服力
duangsuse 2020-03-12 20:35:23
每个实现方式的客观需求都是不同的，Who knows?
不过我就是喜欢有序、有层次的代码，如果正好可配置，那为什么不呢(´∇｀)
超高校
你能作为"有特色"的框架去beat标杆的某些方面，或者成为这个标杆的闭包
duangsuse 2020-03-12 20:07:22
@超高校级的门卫 我也去看过不少同类框架。
他们也的确是“相差无几”，但就我个人来看，他们唯一差的就是，太聪明了…… 太学术了……
比如 https://github.com/h0tk3y/better-parse，它是用了很多很厉害的技术(e.g. codegen)，但不是很工程，而且容易被滥用一些 combinator 的 infix notation
不忘掉 BNF 那套繁琐的 terminal / non-terminal 术语，不摒弃以往 scannerless parser框架 的实现模式，怎么可能弄出 ParserKt 这种泛向的框架的说(≧ω≦)
duangsuse 2020-03-12 20:08:21
下次重构后去跑分！现在还在各种优化接口……
超高校级的门卫 2020-03-12 20:09:26
bnf和scannerless不冲突
超高校级的门卫 2020-03-12 20:09:38
你的泛向在哪里
duangsuse 2020-03-12 20:09:46
泛型解析。
超高校级的门卫 2020-03-12 20:10:09
你举例子
duangsuse 2020-03-12 20:10:14
// Generic parsing for [1, a, b] where (b > a) val ints = Seq(::IntTuple, item(1), *Contextual(item<Int>()) { i -> satisfy<Int> { it > i } }.flatten().items() ) ints.rebuild(1,2,3) //[1, 2, 3] ints.rebuild(1,2,1) //notParsed i.rebuild(1,0,1) //[1, 0, 1]
超高校级的门卫 2020-03-12 20:11:47
哪里泛型了？
duangsuse 2020-03-12 20:12:00
https://github.com/ParserKt/ParserKt/blob/master/README.md#introduction
就是这里的代码示例
超高校级的门卫 2020-03-12 20:12:02
这是parsec都能做到的
超高校级的门卫 2020-03-12 20:12:10
你无非做了一个constraint
duangsuse 2020-03-12 20:12:13
输入是 Int
超高校级的门卫 2020-03-12 20:12:25
这不是什么问题
超高校级的门卫 2020-03-12 20:12:36
haskell parsec是母版
超高校级的门卫 2020-03-12 20:12:44
token是泛型的
duangsuse 2020-03-12 20:13:01
可是我见过所有的 Kotlin parserc 都不能 (＾ν＾)
duangsuse 2020-03-12 20:13:23
而且 Haskell 的 parserc 谈不了性能
超高校级的门卫 2020-03-12 20:13:53
haskell是一个相当快速的语言，你应该多做benchmark
duangsuse 2020-03-12 20:14:08
到处 shallow copy 的 product value mapping 是很难做到服务端的性能要求的
duangsuse 2020-03-12 20:14:43
GHC Haskell 的性能往往要靠特别的优化
超高校级的门卫 2020-03-12 20:14:49
我一直觉得发生shallow copy的是非pure语言使用list的时候
超高校级的门卫 2020-03-12 20:14:59
而haskell整好避免这一点
duangsuse 2020-03-12 20:15:51
而且 Kotlin 是内部支持 imperative 的语言呢，Haskell 是另外的世界
超高校级的门卫 2020-03-12 20:16:21
如果事实如此，那确实是挺不错的。@定理证明器 当年好像没把我的库移植过去完，不然也是个token type可变的
duangsuse 2020-03-12 20:17:31
不过这个里面有不少点子都是我自己想出来的比如 Feed/Pattern (可 read 可 show) 还有 clam, clamWhile, alsoDo, stateAs 什么的
超高校级的门卫 2020-03-12 20:17:37
不过我当年第一个parsing尝试就是在非传统token的type上做的，写完就有人说太naive。我认为不太容易获得认同
超高校级的门卫 2020-03-12 20:17:55
别人看会觉得挺复杂的
超高校级的门卫 2020-03-12 20:18:30
我以前也搞很多新东西，后面发现无非是一个user define的parsec函数
超高校级的门卫 2020-03-12 20:18:57
我对我以前的评价就是，做出了parsec的左递归支持，牛逼。别的，垃圾，闭门造车。
duangsuse 2020-03-12 20:20:58
From big power comes big responsibility比如说，PKT 里 SurroundBy(clamly(parens), stringFor(anyChar)) 你可以在错误提示里获得开括号的 sourceLoc （前提是 input 必须包含 ExpectClose 实例的状态）而手写是这种做法的…… “无结构”写法ANTLR？它做不到，因为它不知道什么是 paired Pattern
超高校级的门卫 2020-03-12 20:23:09
有意思，你可以讲一些你这个开括号错误提示比antlr强在哪儿
超高校级的门卫 2020-03-12 20:23:43
(xxx你会提示(的loc而不是最后一个x的loc?
duangsuse 2020-03-12 20:25:15
不过 SatisfyPattern.clam 和 Pattetn.clamWhile 也的确是受启发的
就是编译原理所谓的“镇静解析策略”
ParserKt 里的 Pattern, read 成功就是 T, 失败了就是 null (notParsed)
所以，clamWhile(pat, defaultValue, messager) 可以提供一个可定制的出错提示
我尽可能把 parserc 在语言可以表达的逻辑的集成方面的优势用到了…… 就那样吧
超高校级的门卫 2020-03-12 20:25:49
这是user define的行为
超高校级的门卫 2020-03-12 20:26:13
用户会选择自己写一个这个功能，而不是记忆你的api
duangsuse 2020-03-12 20:26:57
就像 Java 8 的 obj.someCall()它的 NPE 不会提示 null 的东西是 obj。ParserKt 可以在找不到闭括号的前提下显示expecting ')' (from file:line:column)
超高校级的门卫 2020-03-12 20:28:04
你确定antlr做不到？我认为LL和LR都应该有这个能力，除非parser的失败是在内部的rule
超高校级的门卫 2020-03-12 20:28:29
而内部rule失败，报出外部还没遇到的错误也不太合理
duangsuse 2020-03-12 20:28:42
不过这个错误提示也的确是可定制的相关代码在这里：https://github.com/ParserKt/ParserKt/blob/master/parserkt-ext/src/commonMain/kotlin/org/parserkt/pat/ext/MiscHelper.kt#L48
超高校级的门卫 2020-03-12 20:29:04
这哪个parsec都都可定制
duangsuse 2020-03-12 20:29:16
不确定，但是它不会知道“() 是配对的两个东西”
超高校级的门卫 2020-03-12 20:29:17
这你还要说只有你可定制吗？
duangsuse 2020-03-12 20:29:47
不是只有 ParserKt 可定制，是只有它定制最方便
超高校级的门卫 2020-03-12 20:30:33
这是user define的东西，一定存在kotlin edsl能够对任何parsec后端work
duangsuse 2020-03-12 20:30:58

超高校级的门卫 2020-03-12 20:31:13
你定制方便没有意义，因为用户本来就不期望库里面做一些特殊use case的事情
duangsuse 2020-03-12 20:32:03
谁知道呢？(๑ゝω╹๑)
超高校级的门卫 2020-03-12 20:33:16
像antlr这种次级parser生成器，以及现在的可用parser生成器，都可以正常的报出)没match。至于说要提示没match哪个(，这个需求不具有说服力
duangsuse 2020-03-12 20:35:23
每个实现方式的客观需求都是不同的，Who knows?
不过我就是喜欢有序、有层次的代码，如果正好可配置，那为什么不呢(´∇｀)
超高校
GitHub
ParserKt/ParserKt
Naive one-pass recursive descent, scannerless parser framework for Kotlin - ParserKt/ParserKt
没有价值的，每一遍完全重写的都会让你对问题和解决方案的理解更进一步，无论算法和模型简单或复杂，我相信都是这样。
这一点，我想一味强调“我只花了3小时” “对我来说这太简单了”的人大概是不会明白吧……
这就是我刚才说的，对自己的“胜利”，还是对他人价值的坚持
duangsuse 2020-03-12 21:53:59
所以最好还是不要“智商量化”了吧……
价值是可以量化的，但是如果作概论，两个人直接变成了偏序关系（传递&反对称）……
是不是这么理解，不是完全战胜就是完全打败，有点太世俗呢……
收藏于昨天 群-迂腐的学院派编译技术
这一点，我想一味强调“我只花了3小时” “对我来说这太简单了”的人大概是不会明白吧……
这就是我刚才说的，对自己的“胜利”，还是对他人价值的坚持
duangsuse 2020-03-12 21:53:59
所以最好还是不要“智商量化”了吧……
价值是可以量化的，但是如果作概论，两个人直接变成了偏序关系（传递&反对称）……
是不是这么理解，不是完全战胜就是完全打败，有点太世俗呢……
收藏于昨天 群-迂腐的学院派编译技术
级的门卫 2020-03-12 20:41:16
不管是实现还是使用，我觉得你都没有比别的框架更有序和有层次。可配置这一点是比较明显的，但你也引入了相当的复杂度，我觉得是混淆了user define和library core。
不管怎么说你能写出parsec改进框架，说明你掌握了模式匹配，已经超越了很多的人。望继续加油
duangsuse 2020-03-12 20:44:41
@超高校级的门卫 是 Scala 的库啊，还能解析 Python，我看看
duangsuse 2020-03-12 20:46:22
@超高校级的门卫 受教了^ω^
duangsuse 2020-03-12 20:55:53
( ﾟ∀ ﾟ)不过说起来，个人感觉 FastParse 还是有点冗了
不懂为什么一定要是 runParse(parser, input) ，看起来很多框架都这样的
而且 P("text") 这个语义有点不对啊…… 难道 P 是 regex? 
超高校级的门卫 2020-03-12 20:56:44
runParse是因为大家都相当程度学过haskell，理解，并认可其抽象
超高校级的门卫 2020-03-12 20:57:12
P的语义有什么不对？
超高校级的门卫 2020-03-12 20:57:39
wrap到parser monad中
超高校级的门卫 2020-03-12 20:58:06
类型上更加统一美妙，而不是使用大量没有规律的重载
duangsuse 2020-03-12 20:58:33
说起性能，ParserKt 强调一定要 one-pass （仅过一遍，Feed 流绝不回头）
而多字符判断都是 TriePattern / Contextual 弄的
这个也是 one-pass 同好吗？( ﾟ∀ ﾟ)
duangsuse 2020-03-12 20:59:35
其实因为只能过一遍的原因，ParserKt 里都是没有 string pattern 的，都用可变的 TriePattern 替代了
duangsuse 2020-03-12 21:01:11
@超高校级的门卫 (>﹏<)刚才没看见 P 不只是 P("") 一种用法
超高校级的门卫 2020-03-12 21:04:34
多字符判断靠优化做。parsec默认都是不回溯的。peek(1)也不行
duangsuse 2020-03-12 21:05:20
这个解析器是纯的 [a] recurse&destruct？
直接用符号看起来也是蛮 EDSL 的呢……
ParserKt 很强调 one-pass 和 rebuild (flatten Parse result back to input)
所以不存在 | alternation，连 SDRIES （seq, decide, repeat. item, elementIn, satisfy ) 里的 Decide 解析结果都是 Tuple2<Idx/*=Int*/, T> 呢……
超高校级的门卫 2020-03-12 21:05:29
peek(1)后match出一个rule，是parsec里可以有的一种组合子，不知道是否是你的triepattern
超高校级的门卫 2020-03-12 21:05:56
alternative是为了好写，好组合
duangsuse 2020-03-12 21:06:32
是的，不过那个更灵活其实 Contextual+TriePattern 也是可以做到这种的。
超高校级的门卫 2020-03-12 21:06:51
parsec的alternative也有可以优化的办法，你手工dispatch，代码比较多，而且看不到很多优化点
duangsuse 2020-03-12 21:07:55
Contextual 就是有一个 HEAD 一个 BODY，其中 BODY 的解析器依赖 HEAD 的结果构造
超高校级的门卫 2020-03-12 21:08:53
我一般喜欢把这个叫做parsec的parsergen组合子，不过其实他很平凡，没有名字
duangsuse 2020-03-12 21:09:46
所以说现阶段主要是靠实践者手动做分支判断……https://github.com/ParserKt/examples/blob/master/hanCalc/src/commonMain/kotlin/Calc.kt
超高校级的门卫 2020-03-12 21:10:38
我后期parsing学习步入正轨，就是从优化这个开始的
超高校级的门卫 2020-03-12 21:11:18
我建议你还是以学习为主
duangsuse 2020-03-12 21:12:06
其实这个计算器 虽然幼稚，但也比较有意思……
毕竟 TriePattern 是可变的……
另外我现在还是高中生…… 学习为主的话…… 的确是
(￣o￣) . z Z 呢
超高校级的门卫 2020-03-12 21:13:53
别把自己是高中生拿出来说，没人会觉得这个是亮点。我觉得挺恶心的。我大学开始学的编程，初中开始学编程能达到我水平的也没几个
超高校级的门卫 2020-03-12 21:14:52
parsec都是可变的，是少数可以支持动态添加rule的parsing技术之一。你的话满是尴尬，我不想多说负面语言。你加油，别回了
duangsuse 2020-03-12 21:14:57
@超高校级的门卫 我清楚这个会被人当做是炫耀但是既然你都问了…… 有一点感觉你会认为我是学后端什么的
超高校级的门卫 2020-03-12 21:15:32
没有，我挺认同你的。但我不喜欢你这一副以目前结果自觉满足的样子
duangsuse 2020-03-12 21:16:37
我 不 满 足
我只是来推销（
超高校级的门卫 2020-03-12 21:16:42
你不配
duangsuse 2020-03-12 21:17:02
如果我满足了，就不会回来
因为我早就被冰封喷过一次
duangsuse 2020-03-12 21:17:11

Miko 2020-03-12 21:17:36
你不配hetui
duangsuse 2020-03-12 21:19:02
自大的人是不会接受批评的
我见过这种人，当然这不代表我不自大
那么怎么再谦虚…… 我不发颜表情了好不好
我已经因为杠性能和语法糖的概念定义
被 Tg 上的 Pythonzh 踢过一次了……
duangsuse 2020-03-12 21:19:51
好吧，原来推销是要避嫌的（
duangsuse 2020-03-12 21:21:39
没事（没关系我只单方面认识冰封dalao来这交流下观念，收获颇丰。
今泉影狼 2020-03-12 21:23:18
@duangsuse 知乎上有两个高中生
duangsuse 2020-03-12 21:23:47
哥巴赫猜想？
今泉影狼 2020-03-12 21:23:57
[轻应用]
今泉影狼 2020-03-12 21:24:15
[轻应用]
今泉影狼 2020-03-12 21:24:24
你看看他们的回答和文章
今泉影狼 2020-03-12 21:24:33
这才是高中生应该有的样子
duangsuse 2020-03-12 21:26:01
确实是，但你也不能否认另一个技术侧面和编程风格的“高中生”毕竟就是，什么人都有，健康的技术不应该只有一种风格。
超高校级的门卫 2020-03-12 21:26:32
这是风格问题？
今泉影狼 2020-03-12 21:26:51
前者除了科技发烧友和 telegram 使用之外应该是你的 superset (
duangsuse 2020-03-12 21:28:52
https://www.zhihu.com/people/newbie-tu-xing-cheng-xu-yuan?utm_source=qq&utm_medium=social&utm_oi=680871912008323072
我觉得这个讲得蛮不错的，有没有讲关系式 unification 在 Kotlin 里的实现的文章 可以推荐下
duangsuse 2020-03-12 21:31:07
@今泉影狼 不，是包含交集的两个不同的集合没有道理去给任何事物评价“谁输谁赢”就好像类型系统，也只是程序设计语言的一部分不管它怎么样集成，也不能代表整个语言本身
duangsuse 2020-03-12 21:33:02
你们定下大佬的标准是完全没问题的
但是，现实世界没有“无用的齿轮”，也不能说某人的能力在何层面都不如另一人
duangsuse 2020-03-12 21:36:42
在我看来，知识不是为了让你打败谁，获得怎样的尊重
而是能让你能更多、更深地为其他人做点什么
所以说可读性很重要，不过这也是相对的…… 但它不意味 对于很复杂的问题，就没有更简单的描述方法了
举例、比喻、提纲、缩写、图示、动画
这全都是进一步加强可读性的方法诶
duangsuse 2020-03-12 21:49:56
我不喜欢数学不止是因为我对数字的记忆和计算能力差，更是因为…… 我的风格相当“工程”
我尽可能少做和最终问题无关的事情
而且比起单纯的阅读学习，更希望能先实践再搜集引用（实际上我很怕复杂以及代数式的概念）
我觉得要创新的话，先理解问题还是先理解解决方式 是很重要条件
如果能先做到理解问题，虽说不一定能做到更好，但至少会有所改变，然后让这些改变物竞天择，累积起来。
重复不是
不管是实现还是使用，我觉得你都没有比别的框架更有序和有层次。可配置这一点是比较明显的，但你也引入了相当的复杂度，我觉得是混淆了user define和library core。
不管怎么说你能写出parsec改进框架，说明你掌握了模式匹配，已经超越了很多的人。望继续加油
duangsuse 2020-03-12 20:44:41
@超高校级的门卫 是 Scala 的库啊，还能解析 Python，我看看
duangsuse 2020-03-12 20:46:22
@超高校级的门卫 受教了^ω^
duangsuse 2020-03-12 20:55:53
( ﾟ∀ ﾟ)不过说起来，个人感觉 FastParse 还是有点冗了
不懂为什么一定要是 runParse(parser, input) ，看起来很多框架都这样的
而且 P("text") 这个语义有点不对啊…… 难道 P 是 regex? 
超高校级的门卫 2020-03-12 20:56:44
runParse是因为大家都相当程度学过haskell，理解，并认可其抽象
超高校级的门卫 2020-03-12 20:57:12
P的语义有什么不对？
超高校级的门卫 2020-03-12 20:57:39
wrap到parser monad中
超高校级的门卫 2020-03-12 20:58:06
类型上更加统一美妙，而不是使用大量没有规律的重载
duangsuse 2020-03-12 20:58:33
说起性能，ParserKt 强调一定要 one-pass （仅过一遍，Feed 流绝不回头）
而多字符判断都是 TriePattern / Contextual 弄的
这个也是 one-pass 同好吗？( ﾟ∀ ﾟ)
duangsuse 2020-03-12 20:59:35
其实因为只能过一遍的原因，ParserKt 里都是没有 string pattern 的，都用可变的 TriePattern 替代了
duangsuse 2020-03-12 21:01:11
@超高校级的门卫 (>﹏<)刚才没看见 P 不只是 P("") 一种用法
超高校级的门卫 2020-03-12 21:04:34
多字符判断靠优化做。parsec默认都是不回溯的。peek(1)也不行
duangsuse 2020-03-12 21:05:20
这个解析器是纯的 [a] recurse&destruct？
直接用符号看起来也是蛮 EDSL 的呢……
ParserKt 很强调 one-pass 和 rebuild (flatten Parse result back to input)
所以不存在 | alternation，连 SDRIES （seq, decide, repeat. item, elementIn, satisfy ) 里的 Decide 解析结果都是 Tuple2<Idx/*=Int*/, T> 呢……
超高校级的门卫 2020-03-12 21:05:29
peek(1)后match出一个rule，是parsec里可以有的一种组合子，不知道是否是你的triepattern
超高校级的门卫 2020-03-12 21:05:56
alternative是为了好写，好组合
duangsuse 2020-03-12 21:06:32
是的，不过那个更灵活其实 Contextual+TriePattern 也是可以做到这种的。
超高校级的门卫 2020-03-12 21:06:51
parsec的alternative也有可以优化的办法，你手工dispatch，代码比较多，而且看不到很多优化点
duangsuse 2020-03-12 21:07:55
Contextual 就是有一个 HEAD 一个 BODY，其中 BODY 的解析器依赖 HEAD 的结果构造
超高校级的门卫 2020-03-12 21:08:53
我一般喜欢把这个叫做parsec的parsergen组合子，不过其实他很平凡，没有名字
duangsuse 2020-03-12 21:09:46
所以说现阶段主要是靠实践者手动做分支判断……https://github.com/ParserKt/examples/blob/master/hanCalc/src/commonMain/kotlin/Calc.kt
超高校级的门卫 2020-03-12 21:10:38
我后期parsing学习步入正轨，就是从优化这个开始的
超高校级的门卫 2020-03-12 21:11:18
我建议你还是以学习为主
duangsuse 2020-03-12 21:12:06
其实这个计算器 虽然幼稚，但也比较有意思……
毕竟 TriePattern 是可变的……
另外我现在还是高中生…… 学习为主的话…… 的确是
(￣o￣) . z Z 呢
超高校级的门卫 2020-03-12 21:13:53
别把自己是高中生拿出来说，没人会觉得这个是亮点。我觉得挺恶心的。我大学开始学的编程，初中开始学编程能达到我水平的也没几个
超高校级的门卫 2020-03-12 21:14:52
parsec都是可变的，是少数可以支持动态添加rule的parsing技术之一。你的话满是尴尬，我不想多说负面语言。你加油，别回了
duangsuse 2020-03-12 21:14:57
@超高校级的门卫 我清楚这个会被人当做是炫耀但是既然你都问了…… 有一点感觉你会认为我是学后端什么的
超高校级的门卫 2020-03-12 21:15:32
没有，我挺认同你的。但我不喜欢你这一副以目前结果自觉满足的样子
duangsuse 2020-03-12 21:16:37
我 不 满 足
我只是来推销（
超高校级的门卫 2020-03-12 21:16:42
你不配
duangsuse 2020-03-12 21:17:02
如果我满足了，就不会回来
因为我早就被冰封喷过一次
duangsuse 2020-03-12 21:17:11

Miko 2020-03-12 21:17:36
你不配hetui
duangsuse 2020-03-12 21:19:02
自大的人是不会接受批评的
我见过这种人，当然这不代表我不自大
那么怎么再谦虚…… 我不发颜表情了好不好
我已经因为杠性能和语法糖的概念定义
被 Tg 上的 Pythonzh 踢过一次了……
duangsuse 2020-03-12 21:19:51
好吧，原来推销是要避嫌的（
duangsuse 2020-03-12 21:21:39
没事（没关系我只单方面认识冰封dalao来这交流下观念，收获颇丰。
今泉影狼 2020-03-12 21:23:18
@duangsuse 知乎上有两个高中生
duangsuse 2020-03-12 21:23:47
哥巴赫猜想？
今泉影狼 2020-03-12 21:23:57
[轻应用]
今泉影狼 2020-03-12 21:24:15
[轻应用]
今泉影狼 2020-03-12 21:24:24
你看看他们的回答和文章
今泉影狼 2020-03-12 21:24:33
这才是高中生应该有的样子
duangsuse 2020-03-12 21:26:01
确实是，但你也不能否认另一个技术侧面和编程风格的“高中生”毕竟就是，什么人都有，健康的技术不应该只有一种风格。
超高校级的门卫 2020-03-12 21:26:32
这是风格问题？
今泉影狼 2020-03-12 21:26:51
前者除了科技发烧友和 telegram 使用之外应该是你的 superset (
duangsuse 2020-03-12 21:28:52
https://www.zhihu.com/people/newbie-tu-xing-cheng-xu-yuan?utm_source=qq&utm_medium=social&utm_oi=680871912008323072
我觉得这个讲得蛮不错的，有没有讲关系式 unification 在 Kotlin 里的实现的文章 可以推荐下
duangsuse 2020-03-12 21:31:07
@今泉影狼 不，是包含交集的两个不同的集合没有道理去给任何事物评价“谁输谁赢”就好像类型系统，也只是程序设计语言的一部分不管它怎么样集成，也不能代表整个语言本身
duangsuse 2020-03-12 21:33:02
你们定下大佬的标准是完全没问题的
但是，现实世界没有“无用的齿轮”，也不能说某人的能力在何层面都不如另一人
duangsuse 2020-03-12 21:36:42
在我看来，知识不是为了让你打败谁，获得怎样的尊重
而是能让你能更多、更深地为其他人做点什么
所以说可读性很重要，不过这也是相对的…… 但它不意味 对于很复杂的问题，就没有更简单的描述方法了
举例、比喻、提纲、缩写、图示、动画
这全都是进一步加强可读性的方法诶
duangsuse 2020-03-12 21:49:56
我不喜欢数学不止是因为我对数字的记忆和计算能力差，更是因为…… 我的风格相当“工程”
我尽可能少做和最终问题无关的事情
而且比起单纯的阅读学习，更希望能先实践再搜集引用（实际上我很怕复杂以及代数式的概念）
我觉得要创新的话，先理解问题还是先理解解决方式 是很重要条件
如果能先做到理解问题，虽说不一定能做到更好，但至少会有所改变，然后让这些改变物竞天择，累积起来。
重复不是
GitHub
ParserKt/examples
Example parsers for the ParserKt library. Contribute to ParserKt/examples development by creating an account on GitHub.
🤔 下次一定要让 ParserKt 的应用走上 web
还有我从一个项目里学到 GitHub 里也可以用 <table border= >
应该可以弄一个新 brief
还有我从一个项目里学到 GitHub 里也可以用 <table border= >
应该可以弄一个新 brief
Forwarded from 层叠 - The Cascading