Forwarded from dnaugsuz
🤔 https://github.com/Mivik/KiotLexer/blob/master/src/main/kotlin/com/mivik/kiot/lexer/Document.kt#L5
这里支持 index, length, seek (就是 move) 和 next, hasNext
怎么感觉有点像给 random access 扩展了个
这里支持 index, length, seek (就是 move) 和 next, hasNext
怎么感觉有点像给 random access 扩展了个
Iterator<Char>GitHub
Mivik/KiotLexer
A state-based lexer written in kotlin. Contribute to Mivik/KiotLexer development by creating an account on GitHub.
Forwarded from dnaugsuz
Feed 架构有点太死了感觉（这个版本就只有 peek-1 的 peek, consume() ）
下个版本我会把 ErrorHandler 重命名为更贴切的 FeedError 并且加入 FeedTerminate
我是最近一年才开始用这种「伪动态类型」的架构风格的…… 基本上就是先制定一个功能很少的基类，再利用接口和 instanceof 扩展功能
下个版本我会把 ErrorHandler 重命名为更贴切的 FeedError 并且加入 FeedTerminate
我是最近一年才开始用这种「伪动态类型」的架构风格的…… 基本上就是先制定一个功能很少的基类，再利用接口和 instanceof 扩展功能
Forwarded from Mivik Q
abc abc ab这种，如果来一个"abc ".repeat(2..3)的消耗，那么是需要到ab那里才能决定并回退
Forwarded from dnaugsuz
🤔 其实你也可以学一下
虽然我之前也实现过一个（基于 List 的泛型流回溯），不过 ParserKt 现在是没有回溯功能的（而且我也不打算加入，因为我觉得 peek-1 好像也怪强大的）
其实主要还是害怕支持 backtracking 后，会使得框架实现对新手更为难懂，而 ParserKt 很重视别人理解上的开销……
java.io.Reader ，它们那有个 mark/reset 操作，可以不必暴露完 pos (tell) / seek 虽然我之前也实现过一个（基于 List 的泛型流回溯），不过 ParserKt 现在是没有回溯功能的（而且我也不打算加入，因为我觉得 peek-1 好像也怪强大的）
其实主要还是害怕支持 backtracking 后，会使得框架实现对新手更为难懂，而 ParserKt 很重视别人理解上的开销……
Forwarded from dnaugsuz
https://github.com/duangsuse-valid-projects/Share/blob/master/Others/kt_misc/pkt_7/Parser.kt#L128 #parsing #Kotlin
就是在这里，我定义了
所以说 ParserKt 最开始是有 mark/reset 这种常见操作的
我现在也破除了对所谓 one-pass 的迷信，但因为实现起来相对复杂还是不打算恢复 >1 的预判
当然说白了不允许“预取”说到底是架构上对子解析器程序灵活性的限制，不是说不能预取就根本没法实现（但实践上它还是会对实现复杂文法增加很大难度，举个例子 (/**) ... */ 这种要判两个字符翻译过来是
只不过这是 ParserKt 的选择，如果允许就有点狗拿耗子了，还是要做好自己分内的、能够并且擅长实现的工作才好。
正则擅长做的事情就让它去做，它并不落后；ANTLR 擅长的复杂文法和跨语言就让它生成解析器；ParserKt 的目标虽然不止限于 prototype 或 quick hack，但也就是个小工具，不能包容万物…… 类似 editor highlight 这种经常更新的事对 ParserKt代码就不容易复用，但整体看形式化文法的数据结构是跨任何语言和利用方式的，我很重视它们自己与生俱来的复用性。
就是在这里，我定义了
abstract class StackMarkReset<T>: MarkReset后者被用于实现了
abstract class BufferMarkReset<BUF>: MarkReset
open class Input<T>(private val feed: Feed<T>) 所以说 ParserKt 最开始是有 mark/reset 这种常见操作的
我现在也破除了对所谓 one-pass 的迷信，但因为实现起来相对复杂还是不打算恢复 >1 的预判
当然说白了不允许“预取”说到底是架构上对子解析器程序灵活性的限制，不是说不能预取就根本没法实现（但实践上它还是会对实现复杂文法增加很大难度，举个例子 (/**) ... */ 这种要判两个字符翻译过来是
Repeat(Repeat(. until '*' postfix not ('/')) ) postfix '/' 看起来十分诡异，而且非常不适合解析结果的构造 ）只不过这是 ParserKt 的选择，如果允许就有点狗拿耗子了，还是要做好自己分内的、能够并且擅长实现的工作才好。
正则擅长做的事情就让它去做，它并不落后；ANTLR 擅长的复杂文法和跨语言就让它生成解析器；ParserKt 的目标虽然不止限于 prototype 或 quick hack，但也就是个小工具，不能包容万物…… 类似 editor highlight 这种经常更新的事对 ParserKt代码就不容易复用，但整体看形式化文法的数据结构是跨任何语言和利用方式的，我很重视它们自己与生俱来的复用性。
GitHub
duangsuse-valid-projects/Share
🐕 duangsuse's shared files(e.g. productive software projects, documents) - duangsuse-valid-projects/Share
🤔感觉其实关系式最重要的就是一个
6大基本元素，State, Variable 其实是一家的，State 就是一个 MutableMap，Varaible 则是上面的一个 key，它可能被当成一个 value container 使用也可能被当成 value 使用，反正同时可以是输入和输出，以方便各种计算方式（1+2 = ?; 1+? = 3）
fresh (introduce) 就是作用域策略；然后剩下 Eq,Both, Either 三个 goal 来定义关系、执行计算
关键还是中间的等号，利用相等关系解构出值，而且还有对称性…… 我喜欢把 <= 叫 "from"、 => 叫 "to" (现在改 back 了，因为我嫌它长度不对称)，反正左边是目的右边是源。
关键问题是，怎么让 unification 更“纯粹”点，现在我看到的方法正着 a b 写一遍、反着 b a 也得写一遍，可是有些关系是不需要这么复杂的…… 是不是真的这样呢？
a + b = c 嘛6大基本元素，State, Variable 其实是一家的，State 就是一个 MutableMap，Varaible 则是上面的一个 key，它可能被当成一个 value container 使用也可能被当成 value 使用，反正同时可以是输入和输出，以方便各种计算方式（1+2 = ?; 1+? = 3）
fresh (introduce) 就是作用域策略；然后剩下 Eq,Both, Either 三个 goal 来定义关系、执行计算
关键还是中间的等号，利用相等关系解构出值，而且还有对称性…… 我喜欢把 <= 叫 "from"、 => 叫 "to" (现在改 back 了，因为我嫌它长度不对称)，反正左边是目的右边是源。
关键问题是，怎么让 unification 更“纯粹”点，现在我看到的方法正着 a b 写一遍、反着 b a 也得写一遍，可是有些关系是不需要这么复杂的…… 是不是真的这样呢？
Forwarded from Hacker News
Why I’m Leaving Elm (Score: 108+ in 3 hours)
Link: https://readhacker.news/s/4jXfR
Comments: https://readhacker.news/c/4jXfR
Link: https://readhacker.news/s/4jXfR
Comments: https://readhacker.news/c/4jXfR
https://zhuanlan.zhihu.com/codeInChinese 绝句早就应该开始实现的，你看，他们又做出一个支持 layout 的语言『卓语言』
https://zhuanlan.zhihu.com/p/127020521
有点像 Python 和 Lua 杂交的感觉，而且我不得不承认它还蛮中文，所以说拖得越久对绝句越不利。
虽然导入里的命名非常魔法，文件名不能带“的”（当然绝句的模块化不是 Python 系的，所以没有这个问题，有也可以用强行合法化）
https://zhuanlan.zhihu.com/p/101690331
卓语言看起来应该也是近一年的事情，但无论怎样绝句拖得越久，它的越来越多“独有特性”便会被开始引入这个领域是个事实…… 到最后，最坏的下场是它没有任何“创新”的设计了。
https://zhuanlan.zhihu.com/p/127020521
有点像 Python 和 Lua 杂交的感觉，而且我不得不承认它还蛮中文，所以说拖得越久对绝句越不利。
导入包:卓语言系统,卓操作系统,卓文件系统,卓批处理
导入类:批处理命令,常用转义符,控制台
属于:唯一类型
启动:
输出"控制我的文档桌面显示,通过修改注册表相关数据实现"
输出"请输入要操作的选项代号:1 显示, 2 不显示"
控制台读取文本=>S
如果S=="1"
写入数据0
否则
写入数据1
输出"操作成功,请刷新桌面"
暂停
写入数据(整数X)：
A=注册表"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel"
如果A不存在
A创建
A向键"{59031a47-3f72-44a7-89c5-5595fe6b30ee}"写入X 虽然导入里的命名非常魔法，文件名不能带“的”（当然绝句的模块化不是 Python 系的，所以没有这个问题，有也可以用强行合法化）
https://zhuanlan.zhihu.com/p/101690331
卓语言看起来应该也是近一年的事情，但无论怎样绝句拖得越久，它的越来越多“独有特性”便会被开始引入这个领域是个事实…… 到最后，最坏的下场是它没有任何“创新”的设计了。
知乎专栏
中文编程
因地制宜，尽量用中文写代码
duangsuse::Echo
https://zhuanlan.zhihu.com/codeInChinese 绝句早就应该开始实现的，你看，他们又做出一个支持 layout 的语言『卓语言』 https://zhuanlan.zhihu.com/p/127020521 有点像 Python 和 Lua 杂交的感觉，而且我不得不承认它还蛮中文，所以说拖得越久对绝句越不利。 导入包:卓语言系统,卓操作系统,卓文件系统,卓批处理 导入类:批处理命令,常用转义符,控制台 属于:唯一类型 启动: 输出"控制我的文档桌面显示,通过修改注册表相关数据实现"…
关系式求解器会直接照着文章写（先 Ruby 后 Kotlin），然后 ParserKt 继续开发。
等它成熟一点之后，会考虑创建一个叫 PKNF(ParserKt Normalize Form) 的 DSL 基于 annotation processor 嵌入生成代码
等它成熟一点之后，会考虑创建一个叫 PKNF(ParserKt Normalize Form) 的 DSL 基于 annotation processor 嵌入生成代码
看看就好的频道
Message
我来稍微总结下（前半部分）吧。
大概就是，你们肯定想得到的，Haskell 系程序员不好处理关系，所以作者搞砸了和核心团队的交流情绪（但不至于过激，反正都不开心就是了，作者觉得他和别的社区处得好但唯独Elm糟心所以不全是自己的锅）
问题在于 Elm 0.19 的一些修改，摒弃了原有的 JavaScript native module 的支持，导致很多项目无法迁移语言版本，而开发团队对此视而不见（他们觉得让所有项目迁移到 0.19 的 pure-Elm (no-JS) 对 Elm 有利）
举的例子是作者要在 Elm 里使用 Fluent 并且已经创建好编译器，但 0.19 拒绝了把必要的 Browser Intl 语言本地化 API 合并到 core 里，而他们又不允许第三方发布此类包装，交流又失败。
此外还有独裁——开源远远不止一个"LICENSE"
这个观点很有深度
……这一句话可以说是编程实践上冲突产生的大致原因
总结过来就是“独裁”，不是 Python 里那个“仁慈的独裁”！
后面还讽刺了一下现阶段 Elm 的优化和 JS bridge / user defined infix operator 的关系——Evan “
大概就是，你们肯定想得到的，Haskell 系程序员不好处理关系，所以作者搞砸了和核心团队的交流情绪（但不至于过激，反正都不开心就是了，作者觉得他和别的社区处得好但唯独Elm糟心所以不全是自己的锅）
问题在于 Elm 0.19 的一些修改，摒弃了原有的 JavaScript native module 的支持，导致很多项目无法迁移语言版本，而开发团队对此视而不见（他们觉得让所有项目迁移到 0.19 的 pure-Elm (no-JS) 对 Elm 有利）
举的例子是作者要在 Elm 里使用 Fluent 并且已经创建好编译器，但 0.19 拒绝了把必要的 Browser Intl 语言本地化 API 合并到 core 里，而他们又不允许第三方发布此类包装，交流又失败。
此外还有独裁——开源远远不止一个"LICENSE"
“为了使其他人能在Elm 0.19上试用elm-fluent，我进行了调查并考虑了打补丁（不是长期的fork）的可能性。
我在Elm论坛之外的地方的帖子上共享了此内容（关于elm-github-install问题 ）。
理查德·费尔德曼（Richard Feldman）来到这里试图将其关闭——我不知道他是怎么知道这个的，或者以为他有权这样做? 他对我的评论清楚地表明，如果我给Elm编译器打补丁，我将在Elm社区中不受欢迎 。” 这个观点很有深度
“开源项目应该能够接受fork——领导者必须接受人们这样做的权利，并且社区如果决定当前的领导者没有为自己的利益服务，也需要做好准备。这是开源的重点。
例如，人们为OpenOffice做出了贡献，尽管它是公司“所有”的，因为许可证意味着，如果他们开始以不受欢迎的方式（如他们所愿）投身于社区，社区就能够将其fork并继续开发（如LibreOffice他们做到了）。
一个运行良好的开源项目将理解fork是开源的一项基本功能，因此欢迎它，而不是诉诸威胁来维持控制。 ” ……这一句话可以说是编程实践上冲突产生的大致原因
“因此，我是Elm编译器的主要用户，但是package.elm-lang.org的次要用户。 出于这个原因，我并不抱怨package.elm-lang.org的所有用户都不具有相同的权利-有些人可以上传核心程序包，而其他人则不能。 ”
“我在上面举了的例子甚至在Elm论坛之外也发生过，在Elm Discourse上，讨论受到更严格的控制。
在开始贡献的第一周内，我被删除了一个帖子并禁言一个星期。
我的冒犯是在核心团队宣布计划限制Elm 0.19中的native模块后，发布了使用native模块解决某人问题的解决方案。” 总结过来就是“独裁”，不是 Python 里那个“仁慈的独裁”！
“0.18编译器和0.18库中有大量错误将永远不会修复。 其中许多人已经/有过 pull request 超过一年，但从未 merge。
这些是微小的修复，而不是添加新功能的200行代码。 如果该软件包包含native代码，则无法靠派生一个软件包并在0.19中应用补丁。
您所能做的就是报告该错误，并希望Evan在截止日期（从1周到3年不等）之前对其进行修复。” ——而且这还是个匿名评论，作者称是为避免被 Elm Discourse 和 /r/elm 给 ban 掉 “ 除此之外，社区中过去曾选择做与Evan完全相同的事情并使用kernel code来为Javascript库制作Elm binding的其他人很快被指控“阻挡”了Elm，做了对社区不利的事情（ “选择不阻止。选择在Elm里做那些很酷的事情” ）。
这里的伪善真是无聊。最终，我们不得不说，他是在利用领导者的身份欺负人们为他的项目编写lib，即使这违背了人们的利益。
您可能会争辩说，我们并不是都在编写演示代码来说明Elm体系结构，这是正确的——我们正在做更重要的事情：编写生产代码。
如果您认为演示代码在需要良好的体系结构方面比生产代码更重要，那是在舍本逐末。 ” “ 如果我理解正确的话，Elm领导层会接受不存在社区元过程，也没有建立的打算。领导层认为，不为正常的社区成员提供任何清晰的程序来为Elm做出贡献，或提供任何讨论此问题的论坛，都符合社区的最大利益因为他们不会从讨论中受益。我相信这是傲慢。那就是我们的不同之处。 ” 后面还讽刺了一下现阶段 Elm 的优化和 JS bridge / user defined infix operator 的关系——Evan “
他喜欢数学，在鼓励数学”，但是一旦您了解了上下文，Evan便是唯一真正有权做任何事情的人。#parsing 🤔后面的“只要有
其实，我上次就听到一个纯函数式程序员在说“那些东西都是用户定义的，不需要你的框架去提供它，你的库在理论上没什么特别的东西”
最关键的是傲慢吧…… 总是喜欢说你错了，但不告诉你 错在哪里
更不可能“降低身段”细心给你举例子、做整理把知识解释给你听，这当然是有点妄想了，实际上他们往往链接也不愿意给（反正给了那一堆空洞抽象的长篇大论也没人愿意看……大概排斥也都是互相的吧，但是真的没办法解决这些？）
其实真・大佬程度的这种人往往已经很不傲慢了，但他们为菜鸡提供的温暖也是极其有限（不可否认仍然做了很大的工作）的，显然我没有立场指责，只是说说而已。
[a] (List a) 泛型就解决一切需求”可不止是一个“学院派程序员”在主张呢 https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1#gistcomment-2986411 现在，我了解到elm / parser可以并且确实定义了两个用于解析的运算符，原因与我的库这样做的原因相同。 确实，有时需要使用带有自定义运算符的自定义嵌入式语言来吸引编程人员的精力。 解析是其中的一种，这是Evan承认的，并且确实在elm / parser中使用。
但是，假设elm/parser成为我们需要的唯一解析包是不现实的。 首先，它仅适用于String。 在字节数组上进行解析是很常见的（我要干的事）。
即使已在流类型上对elm/parse进行了参数化，解析器中仍然存在不同的实现和功能折衷（回溯，错误跟踪，错误恢复等），即使它们支持相同的流类型，也使不同的解析器库有用。 其实，我上次就听到一个纯函数式程序员在说“那些东西都是用户定义的，不需要你的框架去提供它，你的库在理论上没什么特别的东西”
最关键的是傲慢吧…… 总是喜欢说你错了，但不告诉你 错在哪里
更不可能“降低身段”细心给你举例子、做整理把知识解释给你听，这当然是有点妄想了，实际上他们往往链接也不愿意给（反正给了那一堆空洞抽象的长篇大论也没人愿意看……大概排斥也都是互相的吧，但是真的没办法解决这些？）
其实真・大佬程度的这种人往往已经很不傲慢了，但他们为菜鸡提供的温暖也是极其有限（不可否认仍然做了很大的工作）的，显然我没有立场指责，只是说说而已。
Gist
The reasoning behind removing user-defined operators
The reasoning behind removing user-defined operators - operators.md
duangsuse::Echo
我来稍微总结下（前半部分）吧。 大概就是，你们肯定想得到的，Haskell 系程序员不好处理关系，所以作者搞砸了和核心团队的交流情绪（但不至于过激，反正都不开心就是了，作者觉得他和别的社区处得好但唯独Elm糟心所以不全是自己的锅） 问题在于 Elm 0.19 的一些修改，摒弃了原有的 JavaScript native module 的支持，导致很多项目无法迁移语言版本，而开发团队对此视而不见（他们觉得让所有项目迁移到 0.19 的 pure-Elm (no-JS) 对 Elm 有利） 举的例子是作者要在…
总的来看 Elm 的 SMVU(state, message, view, update) 和模块化架构我觉得都非常好，但傲慢和独裁是很大的问题
Forwarded from 依云
Python 3.9 里
__main__.__file__ 变成绝对路径了，不用每次用的时候 abspath 一下了呢