Pegjs: 如何在 PEG.js 中定义与模式多次匹配的规则？

请阅读 peg 示例语法。 这里没有错误。 问题跟踪器不适用于帮助请求。 示例语法之一正是您所要求的。

帮助请求的适当位置是 StackOverflow。 问题跟踪器是开发人员用来跟踪损坏的地方，以及包存储库用来衡量项目质量的工具。

Document
  = ClassRow+

ClassID
  = "G04"

ClassTitle
  = title:[^\n]+ { return title.join(''); }

ClassRow = 
  id:ClassID title:ClassTitle '\n'? { return { id, title }; }

一旦你看到这个，请关闭这个问题。 谢谢。

关键是要学会阅读 PEG 语法。 说的是：

1. “一个Document是一个或多个ClassRow 。”
2. “ ClassID是固定字符串"G04" 。”
3. “ ClassTitle是直到下一个换行符但不包括下一个换行符的任何文本。您将称其为“标题”。将标题作为字符串返回，而不是字符数组。”
4. “ ClassRow是ClassID后跟ClassRow 。

因为 ClassRow 以换行符结束，所以换行符有效地开始新行。

我将使用 StackOverflow 来解决我的其他问题，感谢您的回答和解释。

但是，有一些事情我想表达：

1. “问题类型：问题：[是/否]”部分对您提到的指令有点误导。 我将该部分解释为“问题跟踪器是提出问题的正确位置”
2. “examples”：我可以在examples/文件夹中看到 4 个示例语法。 但是，恕我直言，除了“arithmetics.pegjs”之外，它们都不适合（足够简单）初学者（像我或我）。 我知道 PEG.js 正在（重载？）开发中，因此您可能更专注于复杂的现实世界问题/场景是可以理解的。 我只是期望从简单到复杂语法的逐步示例。

请将此视为新人反馈。

“问题类型：问题：[是/否]”部分对您提到的指令有点误导。 我将该部分解释为“问题跟踪器是提出问题的正确位置”

我同意。 我想删除该文本，并在 2017 年提出要求。

之所以有文本，是因为不再运行这个库的 David 厌倦了人们说“这是一个错误”而不查看问题并找到另一个认为存在错误的人，并且没有

例如，这个问题有六个克隆

.

“示例”：我可以在示例/文件夹中看到 4 个示例语法。 但是，恕我直言，除了“arithmetics.pegjs”之外，它们都不适合（足够简单）初学者（像我或我）。

我同意。 我想写很多。

.

我知道 PEG.js 正在（重度？）开发中

肯定不是。

原作者让它闲置了一年，所以他要求新的维护者。

2017 年 5 月接任的新维护者尚未向 master 分支发布一个字节的代码。

我已经开始鼓动收购的过程，因为该库的使用量正在下降，该库从 2014 年开始不支持 javascript，近三年来 NPM 上没有readme ，单字符 AST 修复是一年的问题没有得到答复，新的维护者决定放弃他标记为关闭大量问题的 2.5 年的功能分支，并用他自己用不同语言编写的新内容替换整个库

.

您可能更专注于复杂的现实世界问题/场景，这是可以理解的。 我只是期望从简单到复杂语法的逐步示例。

我相信，在让这个库再次恢复健康之后，用户入职可能是目前最重要的现实世界问题

为了清楚起见，我不是原作者。 @dmajda是。

为了清楚起见，我不是维护者。 没有维护者。

“问题类型：问题：[是/否]”部分对您提到的指令有点误导。 我将该部分解释为“问题跟踪器是提出问题的正确位置”

@ceremcem ，你做的一切都是对的（除了你没有在维基百科上查看 PEG 的描述，也没有尝试手动解析你的语法，之后你的问题，恕我直言，将得到解决）。 您无法知道您的问题只是一个问题或对库中错误的描述。 这只能由开发商决定。 因此，没有规定GitHub 只针对 bug 。 即使在非洲，问题也是问题

一般来说，问题跟踪器用于问题，而不是问题

ceremcem 在 stackoverflow 上会在几个小时内得到答案。 在这里，他等了九天，如果我不说出来，我想他不会得到答案。

一年或更长时间后，许多类似的问题在这里都没有得到解答。 有六个八岁。

.

您无法知道您的问题只是一个问题或对库中错误的描述。

是的，他可以。 他在问“我该怎么做？”

除非他认为解析器不能做到这一点，否则这绝不是错误。

它基本上是解析器中最简单的东西，我相信peg仍然是使用最频繁的 javascript 解析器，尽管这很快就不再是真的了，而且他似乎很聪明，所以我不认为他认为解析器生成器不能多次使用规则

为了他的最大利益，最好将他引导到专为问题设计的资源，而不是图书馆维修，特别是如果问题资源是一个非常活跃的资源，并且图书馆维修资源刚刚宣布它将终止三年的工作并且通常会忽略这样的问题

直到我开始给人们贴标签之前，这个问题没有得到答复，这不是巧合，到目前为止还有六个其他问题

没有做出任何决定。 我在给他建议。

另外，我回答了他的问题。

在 StackOverflow 中，我通常会在几个小时内得到答案，所以我是它的常客。 但是，我的 SO question没有任何活动，所以我来这里问。 基本上，响应时间几乎相同。

我已经看到了问题跟踪器使用的每种组合：

• 仅对于错误报告，如果提供了单独的论坛或邮件组（例如 PaperJS），
• 对于问题和错误报告（RactiveJS <3，FreeCAD_Assembly3 <3）
• 对于我实际上并没有得到的东西，以及一个单独的论坛，通常的嫌疑人接管并代表项目所有者进行交谈，这比其他任何事情都更令人沮丧（比如 KiCAD (grrr)）
• 一无所有（Espruino，AFAIR）。 每个问题都会立即关闭，您被迫在他们的论坛中打开一个适当的线程。

没有一个最佳选择（没有一个适合所有情况），但我确实喜欢对所有事情都使用问题跟踪器。

您无法知道您的问题只是一个问题或对库中错误的描述。

我们已经多次在 FreeCAD_Assembly3 库上看到过这种情况。 我的许多简单、愚蠢的问题都揭示了一个或多个错误。 这发生了，我看到了。

我同意。 我想写很多。

我喜欢你对这个图书馆的态度。 你似乎很在乎。

所以我认为他不相信解析器生成器不能多次使用规则

正确的。 我的意图不是错误报告。 我只是没有找到为多行重用相同规则的方法。

但是，我的 SO 问题没有任何活动，所以我来这里问。

哦，伙计，那里的钉子社区也死了吗？

好难过☹️

好的，如果你已经发了一个 SO 帖子，那么到那时你来这里是 100% 正确的

.

我已经看到了问题跟踪器使用的每种组合：

是的，人们总是违反社区规范

.

我同意。 我想写很多。

我喜欢你对这个图书馆的态度。 你似乎很在乎。

非常。 我想参与2017年的所有权转换，但是有人给出了一个17个主要版本的计划，老所有者相信他们

三年后，那个人放弃了他们的第一个小版本。

事实是公共软件真的很难写。 几乎我认识的每个人，包括我自己，都倾向于说“在 X、Y 和 Z 完成之前，这个版本还没有准备好”。

然后当 Y 完成时，你意识到你还需要 V 和 W。

然后当 Z 完成时，你意识到你还需要 S、T 和 U。

然后当 V 完成...

这就是0.11.0在 2017 年开始使用六个功能的方式，并在 2020 年因跟踪器中错误标记为关闭的一百个合并而死亡

公共软件的一部分规则是频繁的小版本发布。 这一直是 peg 的一个问题，但软件的质量如此之高，以至于我们还是忍受了它。

然后 dmajda 离开了，一切都停止了。

我们耐心地等待了很长时间。

但是新来的人现在把它称为他的爱好项目，并说他放弃了整个事情，转而支持他写的一些新的和不相容的东西。 而且即使它有相同的 AST 和相同的功能集等等，它背后也不会有十年的社区调试，我也无法切换

你知道，如果他想写一个新的、更强大的 PEG 解析器，很好，很好，继续。

但是他不会通过假装自己是维护者然后从不维护，然后接管这个人的图书馆社区和职位，并将他自己的永远不会发布的软件取而代之来杀死这个人

是时候让一个健康的过程重新开始了。 新的维护者建立了一个由初级开发人员组成的微型社区，他们实际上是在提倡让这个库死掉而不是拯救它

很明显，急需改变

.

我只是没有找到为多行重用相同规则的方法。

如果您再次找不到答案，请随时标记我

也就是说，通常我会在谷歌上搜索示例，并且因为这个库曾经非常受欢迎并且被大量使用（如果当前的图书馆凶手只是在替补席上腾出空间让另一个人帮助，那么可能会再次出现），有足够多的例子在那里覆盖你需要找到的东西

不过，一般来说，我希望有人在我新手时告诉我的是我在“关键是要学会阅读 PEG 语法”的评论下所说的话

一旦你学会阅读那种讨论形式的 PEG 语法，思考它们也变得非常容易，到那时它们突然变得非常容易编写

这就像一个电灯开关。 没有坡道。 直接从不可能到容易

这就像一个电灯开关。 没有坡道。 直接从不可能到容易

你鼓励了我！ :) 所以当我只能看到一些“胡言乱语”的规则集时，我不应该感到如此愚蠢 :)

如果您再次找不到答案，请随时标记我

我不想滥用这个，所以如果值得询问或者我应该多搜索一下网络，每次都会很难打电话。 这是一个慷慨的提议，谢谢。

很明显，急需改变

我看到您在 fork 中启用了“问题”部分。 当你只是一名乘客时，这总是一个好兆头，试图通过冲进驾驶舱来驾驶一架客机。 这是好事。

如果有活水源，不管你在路上放什么，它总能找到流动的方式。 如果没有流动，因为它的源头被排干了，那就没有办法了。 源头就是需求。 你的态度表明水的源头非常活跃。

所以我很好奇，你为什么不接手？ 这就是我为加载条库所做的。 我意识到开发停滞不前，所以我从自己的问题开始着手解决问题，并为每个分支创建拉取请求。 过了一段时间，原作者决定继续他的工作，我们就可以走了。 您认为这是一个可行的解决方案吗？

你鼓励了我！ :)

我很高兴。

.

这就像一个电灯开关。 没有坡道。 直接从不可能到容易

所以当我只能看到一些“胡言乱语”的规则集时，我不应该感到如此愚蠢:)

不。 解析器是“这很荒谬，然后突然变得很容易”的极端案例。

这是踢球者 - 相对而言，钉住很容易。 其他的往往只是残酷的。

在我看来，学习peg有四大问题。

1. 没有任何结构良好的介绍材料
2. 有很多中级的例子，但你必须擅长谷歌才能找到它们
3. 那里也有不好的例子，需要经验才能识别它们
4. 你必须能够“这样想”，而这不会立即发生

我一直在考虑制作一些视频教程。 我相信他们会让这_far_更容易理解。

.

我不想滥用这个，所以如果值得问的话，每次都很难打电话

一周一次就好了。 了解我有时反应迟钝

.

我看到您在 fork 中启用了“问题”部分。 当你只是一名乘客时，这总是一个好兆头，试图通过冲进驾驶舱来驾驶一架客机。 这是好事。

我几乎没有开始。 首先我想看看真正的回购是否可以被拯救

从叉子上做这件事会更加困难。 我会丢失所有 PR 和所有交叉引用，以及所有关闭的未合并或关闭的已删除材料，其中一些非常有价值

.

所以我很好奇，你为什么不接手？

我想。

此时，相关的密码和身份验证都在一个人的手中，他们还没有回应。

走着瞧。

.

我意识到开发停滞不前，所以我接手解决问题，从我自己的问题开始，并为每个分支创建拉取请求

这是一个特殊情况

发布的是0.10.0

新的维护者允许0.11.0分支在三年内无限增长，然后决定取消它，转而支持他从零开始单独编写的0.12.0

没有什么可以放 PR 的。 npm中的内容来自 2017 年，新维护者下github中的内容在三年后被取消而从未发布

.

过了一段时间，原作者决定继续他的工作，我们就可以走了。 您认为这是一个可行的解决方案吗？

如果替换维护者愿意允许，这大致正是我想要的。

我有点怀疑大卫会回来，但如果他回来了，那就太棒了

因此，我想再次把它变成一个标准的开源项目

您认为这里最重要的 3 个问题是什么？

我认为说对我来说最重要的问题有点危险，因为这里有相当多的人比我在peg拥有更多的经验，如果他们说“实际上是另一回事， “我很可能会听。

为此，我想提醒一下，虽然我很高兴在这里进行开发，但我在这里的兴趣是作为维护者。

这是，我认为，很多人没有得到的东西：开发和维护编码真的，真的不同。

• Development coding想要大的新想法、新功能、新的华而不实的想法。
• Maintenance coding想要在小问题聚合并使某些好的东西无法使用之前解决它们。

我很高兴做一些开发编码——也许甚至期待一些——但这里还有其他人更适合它。 因此，我想明确表示：我的实际目标是让他们能够再次贡献 PR，就像他们过去一样。

也就是说，为了表明我的个人观点：

1. 恢复正常的发布节奏

peg.js绝对不能再有魔法分支。 这就像他妈的一环。 这听起来很棒而且很强大，但它不是该死的工作，最后，你是咕噜。 这不是svn 。 在史蒂夫鲍尔默的声音中， feature branches 、 feature branches 、 feature branches 、 feature branches 。

版本应该是功能的结果，而不是功能计划的收集点。 我们不是一家 1980 年代的公司，我们不应该像一个那样做计划。

唯一应该同时使用多个功能的情况是在不可避免的情况下，例如修补功能以应对外部升级，或者真正无法分开的事情。 哦，你认为这与另一个功能有关吗？ 太好了，把它放在2.31.0中，我们需要把2.29.0拿出来，而那边的其他东西很可能是30 。

人们一直把未成年人当作专业人士对待。 这就是未成年人从未出现过的原因：它被挂在与专业相同的行为陷阱上。 只是不要他妈的这样做™。

再具体一点，

• 我相信，人们在很大程度上已经失去了对这个图书馆不再存在的信心。
• 三个月的每周发布会让人们再给它一次机会。
  
  
  
  • 三个月的每周发布实际上非常容易实现
  
  
• 如果我们不只是取出0.12.0 ，还有0.13.0 - 请注意我并没有说其中的内容，而且我认为这无关紧要 - 那么我们会在1.0.0上实战
• 只是通过这里的开放和封闭的未合并 PR，有大量的力量和美丽，2015 年左右的评论就像“我稍后会研究它”。 做一个慷慨的人并找到分享权威的空间将有助于peg不仅活起来，而且开花
• 为此，我不想成为艺术家。 我想成为策展人。

2. 将文档和测试放到一个可以接受的地方

每个人都在谈论这个，但我的爱好有限状态机目前有 3500 个单元测试和 100% 的文档覆盖率，所以，请认真对待我。

我真的非常相信测试。

我编写的另一个库是状态机的一半大小，复杂度显着降低。 对状态机进行全面的语言更改比对网络处理程序进行小的更改要容易得多，因为网络处理程序的测试很差，你必须付出真正的努力来确保某些事情是正确的。

密克罗尼西亚联邦？ 不，测试很棒，他们会抓住你

每次我接触到它们中的任何一个时，这种特定的对比都会以残酷的清晰提醒我，测试对于至少对我来说是值得信赖的东西实际上是多么重要。

我认为在peg.js上工作的很大一部分问题在于测试和文档是一团糟。 我认为是时候改变了。

3.删除时髦的废话。

• 我不是一个 Ruby 人，但是，Ruby 人对按惯例进行配置有一个真正的观点。 我根本不会 Ruby，但我仍然可以坐下来了解项目是如何工作的，因为它们都是这样工作的，如果我没有得到任何东西，我可以问别人，他们不需要访问权限，因为他们都是这样工作的
• peg在这方面面临四个问题
  
  
  
  1. peg是一个非常早期的javascript库，它在社区规范存在之前做出了一大堆基本选择。 事实上，几个社区的规范都是因为大卫； 在挂钩之前，很多人认为多包装很难，所以现在在这方面的开拓者之一在同一方面有问题地落后，这有点令人心碎。 话虽如此，除了大卫提前做对的出色事情之外，他做错了一些事情，而当时一些正确的事情已经不复存在了。 许多小的更改将导致开发人员体验发生根本性的变化。
  
  
  2. 应该重新建立社区规范。
     
     
     
     
     
     1. node项目应该有某些工作方式。 这包括生成针对浏览器的输出，因此，节点项目显然是正确的现代工作方式
     
     
     
     2. 这仍然是一个手工自动化的浏览器项目。 那应该改变
     
     
     
     3. 进入正确编辑README的位置是一项重大的学习挑战。 三年后，当前的维护者仍然没有成功（！），最后两个版本的原始开发者也没有
        
        
        
        
        
        
        
        • 这是愚蠢的。 应该是微不足道的项目部分正在破坏，因为它们不是以简单的正常方式完成的。 它们应该以简单的常规方式完成，但这需要了解节点并准备好做无聊工作的人。
        
        
        
        
     
     
     
  
  
  3. peg既是极端自动化的受益者，也是受害者。
     
     
     
     
     
     • 没有它， dmajda很可能无法达到他所做的那样。 我当然不能对我的东西。
     
     
     
     • 但是，这是 2011 年的自动化，而不是 2020 年的自动化
     
     
     
     • 这也是 2013、2014、2016 和 2018 年的自动化。 这些东西遍布 zeit，现在，github pages，一个 yahoo 个人帐户，gitlab，几个奇怪的跟踪和自动部署服务，可能还有一堆我还没有找到的东西
     
     
     
     • 这只是为了在崩溃中幸存下来或与热门的新事物玩耍而不断挣扎的工具。 仔细的工具选择导致设计的持久性。 实际的repl现在几乎可以使用十年了。 如果“哦闪亮”被视为危险信号，其他一切都可以。
     
     
     
     • 这应该移到每个人都理解的gh pages和gh actions中，并且永远保持孤独
     
     
     
  
  
  4. 新的维护者选择深入研究不常见的工具和边缘化策略。 因此，您必须安装一个新的包管理器来提供错误修复，并学习一种不常见的源代码布局，它以一种令人困惑的方式与一组看似真实产品的不相关的源代码在常规源代码布局中共存。
     
     
     
     
     
     • 当第三方提供了一个允许标准语言包管理器也可以工作的修复程序时，他拒绝了它。
     
     
     
     • 坦率地说，这种行为在社区项目中是不可接受的。 它使图书馆更难做出贡献。
     
     
     
     • 其中一些极端主义工具已被其他极端主义工具取代，所以他不会去追求他知道的东西； 他正在尝试。 与此同时，我们等待基础知识，例如 AST 中的拼写错误，例如修复npm readme $ 或合并es6 modules ，一次持续三年。
     
     
     
     • 坦率地说，在0.12.0 rebake 中，模块 yarn stuff 中的模块之类的东西就会出来。 David 的构建材料自 2011 年以来一直有效。2018 年的新东西已经在 2020 年被打破。没有更多的业余技术。
     
     
     
  
  
• 我能不能得到一个 ES6 导出

但你会注意到这些实际上都不是关于软件本身的

我不认为这里的软件是问题

我认为这个过程是，在较小程度上，项目

如果@futagoza允许，这些就是我要解决的问题

如果我们放下骄傲，选择图书馆的大型社区需求而不是我们的爱好项目兴趣，这个图书馆可以在 30 天内恢复生机

让爱好重写成为叉子

让维护者开始维护

@StoneCypher我喜欢你的能量 :-) 我过去（在 dmajda 时代）曾经使用过 pegjs，我非常喜欢它。

只是叉它，不要打架。 事情可以而且会在以后安定下来。 如果社区跟随你，那么你就不需要关心现有的“钥匙持有人”或类似的东西。 建立声誉需要时间，但也是必要的。 不要再浪费时间争论了。

八，你的叉子会在未来的某个时候让它“回到原点”，否则它就会有自己的生命。 这两个选项都是有效且良好的 IMO。

请用“做一个叉子”的废话来阻止它。 其中有四个，你不知道它们是什么。 分叉不会保存任何现有的下游消费者，不会保存 PR，不会保存问题，不会承载社区，也不会可见。

人们已经尝试了三年。 这是行不通的。

不要继续提供此建议。

@futagoza - 每个人都放弃了你做正确的事。 五个人告诉我分叉图书馆，因为他们希望你拒绝修复，并保持对你正在杀死的图书馆的控制。

我相信他们期望的原因是，我发现有十几个人为你提供帮助，帮助你完成你承诺但从未做过的事情，而每次你说“不，我很快就会去做。 "

做你应该在 2018 年做的事，把维护交给真正会维护项目的人。 停止杀死这个图书馆，停止杀死这个社区，并让开。

@StoneCypher John，当我建议创建一个分叉时，我是认真的。 分叉一个项目是开源给你的一个很好的选择，特别是如果你觉得它需要改变或者它正在死去。 不，我没有任何问题，你不需要写信给我 DM 只是为了问我这个问题。

当我说“不要再给出这个建议”时，我也是认真的。

我喜欢这次谈话。

@StoneCypher我在这里不同意你的观点，因为我看到的正好相反：

1. 我决定开始学习 FreeCAD。 但是，有一个问题：它的“装配模块”不完整，所以我们几乎无法创建复杂的装配，这使得它对专业工作毫无用处。
2. 一个家伙， realthunder决定解决这个问题。 他需要改变一些核心属性来达到目的，这反过来又使他的分叉与主流分支不兼容。 他失去了所有用户，几乎所有社区。 除了少数人，他没有支持者（这是我所看到的）。 据我了解，他也没有活跃用户。
3. 我检查了他的文档¹ ，尽管开发停滞了一年（那是我当时看到的），但我做了数学（一个有趣的数学）并决定试一试。
4. 我问了很多问题¹ ，他耐心地回答。 同时我把我学到的东西做笔记，这样就做了一个很好的介绍材料。
5. 人们不鼓励¹使用他的分支，声称他是孤独的作者和维护者，他的工作在可持续性方面不应该被信任。 我只是忽略了他们。
6. 他的 pull request 很长时间没有被合并（大约一年左右）。

最近，他的 PR 开始被审查。 经过大量的工作，他的分支终于和主流兼容了。 在下一个版本中，我相信他的分支会并入主流。

与此同时，出现了严重的财务问题。 他是唯一的维护者，少数用户的捐赠无法让他生存。 我决定在土耳其这里教授 FreeCAD/Assembly3，并出售支持以支持财务。 我向他求婚，这被接受了。 我提出了所有必要的申请，以成为一个享有盛誉的基金会的培训师，最近被接受了。

有时 1 人足以生火。

并让开

不同意。 让他们留在路上。 好的动机总会找到出路。 如果不能，那是因为它没有那么好。

我明确而明确地没有收集有关此主题的建议。

这个图书馆需要复活。 如果我没有充分解释，我很抱歉，但我收到的回复未能解决提出的任何实际问题。

人们的生活和工作都依赖于此。