脚本语言的词法分析

Question

我正在尝试为资源API创建一个简单的脚本。我有一个资源API，主要是以结构化的方式创建游戏资源。我想要的是处理这个接口，而不是每次我想要一个资源时都创建c++程序。因此，我们(我和我来自uni的讲师)决定创建一个简单的脚本来创建/编辑资源文件，而不需要每次都编译。还有其他一些不相关的因素，我需要一个命令行界面，而不是GUI程序。

无论如何，下面是脚本示例：

<path>.<command> -<options>
/Graphics[3].add "blabla.png"

这个脚本语言不是我设计的，是API的所有者设计的。'.‘之前的那部分你可以猜到'.‘后面的路径和部分。作为第一步，我尝试创建left部分的语法，因为我认为我可以在搜索有关词法分析器和解析器的信息时使用它。问题是，当涉及到解析和编程语言时，我缺乏经验，并且我不确定它是否正确。这里有一些更多的例子和左边的语法。

dir -> '/' | '/' path
path -> object '/' path | object
object -> number | string '[' number ']'

这个语法是不是很乱，我不知道。有5种不同的可能性，它们是：

String
"String"
Number
String[Number]
"String"[Number]

它必须以'/‘符号开头，如果它是唯一的符号，我将接受它作为根。

现在我的问题是如何从词法上分析这个脚本？有什么特别的方法吗？我的词法分析器应该做什么和不应该做什么(我读到一些词法分析器在一定程度上也做语法分析)。你认为语法等在技术上合适吗？我应该使用哪种解析方法(递归下降，LL等)？我正在努力让它成为一件技术上合适的工作。它不是商业的，所以我有时间，这样我就可以更好地学习词法分析和语法分析。我不想使用解析器库。

Answer 1

我的词法分析器应该做什么，不应该做什么？

它应该：

• 忽略可忽略的空格和注释(如果有这样的标记，请跟踪源位置，以便生成有意义的错误消息。

它不应该尝试解析输入，尽管这对于这样一种简单的语言来说是非常诱人的。

在我看来，您有以下令牌：

原子字符串、空格、线性空格、

• punctuation:字符串(通常称为“new-line
• numbers
• unquoted”或"ids")
• quoted / (可能与未加引号的字符串具有相同的标记类型)

我不确定-options的语法是什么，但它可能包含更多的可能性。

选择返回linear-white-space (即只包含制表符和空格的序列)作为标记有点可疑；它会使语法变得相当复杂，特别是因为可能有一些地方可以忽略空格，比如行的开头和结尾。但我的直觉是，您不希望在路径中使用空格，并且您计划在命令名和其参数之间使用空格。也就是说，您想要禁止：

/left /right[3] .whimper "hello, world"
/left/right[3].whimper"hello, world"

但也许我错了。也许你乐于接受这两种情况。这会更简单，因为如果两者都接受，那么您就可以完全忽略线性空格。

顺便说一句，经验表明，使用换行符来分隔命令可能很笨拙；迟早需要将命令分成两行，以避免必须购买额外的监视器才能看到整行命令。将\作为要继续的行上的最后一个字符的约定(由bash和C预处理器等使用)是可能的，但可能会导致恼人的but (比如在\后面有一个不可见的空格，从而阻止它真正继续该行)。

下面是100%的个人观点，免费提供。因此，无论它有什么价值，都要接受它。

，我正在努力使它成为技术上合适的作品。它不是商业的，所以我有时间，这样我就可以更好地学习词法分析和语法分析。我不想使用解析器库。

在我看来，这里有一个矛盾。或者可能有两个矛盾。

技术上合适的工作将使用标准工具；至少一个词法生成器，可能还有一个解析器生成器。它之所以这样做，是因为，如果使用得当，提供给工具的词汇和语法描述准确地记录了实际的语言，并且工具保证所需的语言是实际识别的语言。编写即席代码，即使是简单的词法识别器和递归下降解析器，尽管它可能很优雅，但它的自我文档化程度较低，可维护性较差，对正确性的保证也较少。因此，最佳实践是“使用标准工具”。

其次，我不同意你的讲师(如果我根据你的评论正确理解了他们的建议)，即编写特别的词法分析器和解析器有助于理解词法和解析理论。事实上，这可能会适得其反。自下而上的解析在理论上和实践上都非常优雅，几乎不可能手工编写，也完全不可能阅读。因此，许多程序员更喜欢使用递归下降解析器或Pratt解析器，因为他们理解代码。但是，这样的解析器不如自下而上的解析器强大(特别是完全通用的GLR或Earley解析器)，而且它们的使用会导致不必要的语法妥协。

您不需要编写正则表达式库来理解正则表达式。这些库抽象了笨拙的实现细节(有很多实现细节，它们真的很笨拙)，让您专注于创建和使用正则表达式的本质。

同样，你不需要编写编译器来理解如何用C编程。在你有了一个很好的C语言基础之后，你可以通过理解它是如何翻译成机器码来提高你的理解能力，但除非你计划从事编译器编写，否则了解晦涩的优化算法的细节并不会让你成为一名更好的程序员。或者，至少他们不是你议程上的第一位。

类似地，一旦您真正理解了正则表达式，您可能会发现编写一个库很有趣。或者不是--你可能会发现它非常令人沮丧，并在几个月的努力工作后放弃。无论哪种方式，您都会更欣赏现有的库。但首先要学会使用现有的库。

解析器生成器也是如此。如果您想了解如何将编程语言的想法转换为精确和可实现的内容，请学习如何使用解析器生成器。只有在您掌握了解析理论之后，您才应该考虑专注于低级实现。