javascript - JS词汇-多行字符串

标签 javascript parsing compiler-construction interpreter lex

我正在研究JS词法分析器。在JS中,单行字符串从“或”开始,并以相同的字符结尾,除非该字符前面带有反斜杠。

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

有什么实际的原因为什么不允许换行作为字符串的内容?

最佳答案

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

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

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

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

这也使开发人员工具(例如编辑器和语法突出显示工具)在键入程序文本时难以处理。

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

不论好坏,语言都是根据特定的主观判断设计的,如果语言成功,这些判断将成为永久性的特征。如果您使用的是语言,则必须接受这些东西,而这些东西通常不值得关注。您已经习惯了它们,或者找到了自己的语法怪异来编程的另一种语言。

当您设计自己的语言时,您将需要解决大量的句法问题,并且由于没有客观正确的独特解决方案,无疑会遇到答案不明确的情况。无论您做什么,都会有人想和您争论。也许您可以推荐他们这个答案。



笔记:


实际上,有一个历史原因不允许使用多行字符串文字,这很清楚,但几十年来一直无关紧要。

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

为了使所有行的长度相同,需要用空格字符填充行。显然,这会使多行字符串文字变得笨拙,这就是为什么C从来没有允许多行字符串文字,而是依靠一种语法功能,在该语法功能中,连续的字符串文字被自动连接成单个文字。

最后,固定行长文件系统被证明是不受欢迎的,而且我认为这些天您不会碰上一个。但是,仔细阅读C和Posix标准后,您会发现,这些文件系统必须仍然可以通过兼容的实现来使用,其结果是,必须准备一个完全可移植的程序来处理输出的行长限制和输入的尾随空白。

关于javascript - JS词汇-多行字符串,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55149649/

相关文章:

javascript - 点击后返回初始状态

javascript - 在重置循环之前使 slider 中的最后一个图像暂停( slider 从头开始)

objective-c - 使用 Objective-C 解析 VCALENDAR (ics)

c++ - sizeof() 的值是由编译器还是链接器决定的?

javascript - 在本地存储中保存并返回随机生成的字符串

asp.net - 在 ASP.NET 和 Javascript 中使用复选框

ios - 使用 Codable 解析 JSON 响应会 swift 出错

python - 从指定字节偏移量的文件中获取行

parsing - 构建 LR(1) 配置前瞻

c# - C# 编译器是开源的吗?