是否存在[词法分析器]的目的的正式定义?
不是。词法分析器是实际编程世界的一部分,对此正式模型是有用的,但不是确定性的。一个声称做某事的程序当然应该做那件事,但是“词法分析我的编程语言”并不是一个足够精确的需求陈述。
…或明确的最佳使用做法
如上所述,词法分析器应该按照它的意图去做。它也不应该试图做其他事情。应避免代码重复。理想情况下,代码应该是可验证的。
这些最佳实践激发了一个成熟的文档良好的扫描程序框架的使用,该框架的输入语言翻译为要分析的词法语法的描述。但是,基于特定编程语言特性的实际考虑通常会导致与这种理想的偏差。
有一个词法分析器可以将每个输入字符转换成一个令牌似乎没有什么明显的错误,
在这种情况下,词法分析器将是多余的;解析器可以简单地使用输入流。这被称为“无扫描仪解析”,它有其倡导者。我不是其中之一,所以我不会讨论利弊。如果你有兴趣,你可以从Wikipedia article开始,并按照其链接。如果这种风格适合你的问题领域,那就去做吧。
在某些(上下文无关)语言中,不可能发生这样的情况:“令牌”的预期概念可能依赖于上下文吗?
当然。一个典型的例子是在EcmaScript正则表达式“文字”中找到的,它需要用完全不同的扫描仪进行词法分析。 EcmaScript 6还定义了需要单独扫描环境的字符串模板文字。这可以激发无扫描处理,但它也可以用带词汇反馈的LR(1)解析器来实现,其中特定标记非终端的缩小动作导致切换到不同的扫描器。
但是,如果让一个词法分析器区分(例如,“一元减法”和通常的二进制减法之间),而不是将其留给解析器,是否可以接受?
任何东西都可以接受,但这个特殊的例子让我觉得不是特别有用。 LR(甚至LL)表达式解析器不需要任何词法扫描程序的帮助来显示减号的上下文。 (朴素运算符优先级语法确实需要这样的帮助,但更深思熟虑的运算PREC架构不会。但是,LALR解析器生成的存在或多或少地避免了对运算PREC解析器的需要。)
一般发言,对词法分析器能够识别语法情况下,它需要复制解析器所做的分析,从而违反了代码开发的基本最佳实践(“不重复的功能”)之一。尽管如此,它可能偶尔有用,所以我不会主张绝对禁止。例如,对于YACC /野牛状生产规则许多解析器补偿这样一个事实:幼稚语法是LALR(2)由专门标记ID的令牌被紧跟一个冒号。
又如,再次从EcmaScript的拉伸,是自动的分号插入(ASI),其可以使用查找表,其键是连续的令牌的2元组来完成的高效处理。同样,Python的空白感知语法可以方便地通过词法扫描程序的帮助来处理,这些扫描程序必须能够理解缩进是否相关(例如,不在括号或大括号内)。
如何对这条规则:“一个词法分析器必须线性时间和数空间的工作”? – Alexey
另一个可能的规则:“一个词法分析器消除源代码格式” ...... – Alexey