首页 > 解决方案 > JS lexing---多行字符串

问题描述

我正在制作一个 JS 词法分析器作为我学习的一部分。在 JS 中,单行字符串从 " 或 ' 开始并以相同的字符结束,除非该字符前面有反斜杠。

在我当前的代码中,我遍历每个字符并将它们附加到基于“字符串”或“正则表达式”等标志的现有标记中。所以用 " 或 ' 实现多行字符串感觉很自然,因为它似乎不会影响我的词法分析器的任何其他部分

是否有任何实际原因不允许换行作为字符串的内容?

标签: javascriptparsingcompiler-constructioninterpreterlex

解决方案


许多语言(但不是全部)禁止字符串文字中未转义的换行符。所以 JavaScript 在这里肯定不是唯一的。

但动机实际上与词法分析的难易程度或效率无关。事实上,对于词法分析,最简单的语法是允许任何字符,而不必包括特殊情况检查。[注1]

不过,还有其他考虑;值得注意的是,程序可读性和易于调试的重要性。长字符串会给阅读代码的人带来额外的负担,因为他们可能不知道程序文本的一部分实际上是字符串文字的一部分。(多行注释也有类似的问题,这就是为什么以某种方式标记长注释中的每一行通常被认为是一种很好的风格,例如在左边距垂直列星号。字符串不存在这样的解决方案文字,虽然。)

此外,未终止的多行字符串可能会很烦人。如果字符串不能跨行,则会在包含问题的行上检测到错误。但是多行字符串可能会一直持续到下一个字符串的开头,然后当下一个字符串的内容被意外解析为程序文本时触发语法错误。或者更糟糕的是,导致对应该是程序文本的完全不正确的解析,然后是另一个不正确的字符串文字,从第二个文字结束的地方开始,并从那里继续。

这也使得开发人员工具(例如编辑器和语法荧光笔)难以处理正在键入的程序文本。

最后,您可能会或可能不会发现这些论点令人信服,并且语言设计者也可能有其他审美偏好。我真的不能代表 JavaScript 语言的原始设计者说话,而且我们都无法及时与他们争论,甚至可能改变他们的决定。

无论好坏,语言都是根据特定的主观判断设计的,如果语言成功,这些判断就会成为永久的特征。如果你使用一种语言,它们是你必须接受的东西,而且它们通常不值得痴迷。你习惯了它们,或者你找到了一种不同的语言来编程,它有自己的语法怪癖。

当你设计自己的语言时,你需要解决大量的句法问题,你无疑会遇到因为没有客观正确的唯一解决方案而导致答案不明确的情况。无论你做什么,都会有人想和你争论。也许你可以让他们参考这个答案。


笔记:

  1. 实际上有一个历史原因不允许多行字符串文字,这更清楚,但几十年来或多或少无关紧要。

    从前,普通文件系统将文本文件视为固定长度行的线性数组(通常为 80 个字符行,与 Hollerith 卡匹配)。这种文件系统的一个优点是它可以立即导航到文件中的特定行号,因为所有行的长度都相同。但无论如何,对于在穿孔卡片上输入程序的系统,固定长度的行只是环境的一部分。

    为了使所有行的长度相同,需要用空格字符填充行。这显然会使多行字符串文字变得尴尬,这就是为什么 C 从未允许多行字符串文字,而是依赖于连续字符串文字自动连接成单个文字的语法特性。

    最后,固定行长度的文件系统被证明是不受欢迎的,我认为你现在不太可能遇到一个。但是仔细阅读 C 和 Posix 标准表明,这样的文件系统必须仍然可以通过符合实现的方式使用,因此必须准备一个完全可移植的程序来处理输出的行长度限制和输入的尾随空格。


推荐阅读