没有价值的,每一遍完全重写的都会让你对问题和解决方案的理解更进一步,无论算法和模型简单或复杂,我相信都是这样。
这一点,我想一味强调“我只花了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
Forwarded from Deleted Account
也可以这么写
或者这么写
fun curtain(visible: Boolean, vararg views: View) {
require(views.isNotEmpty)
val visibility = if (visible) View.VISIBLE else View.INVISIBLE
for (v : views) v.visibility = visibility
}或者这么写
fun curtain(visible: Boolean, vararg views: View): Unit
fun curtain(visible: Boolean): Nothing = throw IllegalArgumentException()