许多编程语言的语法要求根据"maximal munch"原则对它们进行标记。也就是说,令牌是根据输入流中可能的最大字符数构建的。
PLY的词法分析师似乎并不适用这一原则。例如:
import ply.lex as lex
tokens = ('ASSIGNMENT', 'EQUALITY')
t_ASSIGNMENT = r'[+\-*/]?='
t_EQUALITY = r'=='
lexer = lex.lex()
lexer.input('==')
for tok in lexer:
print(tok)
根据“maximal munch”,此代码的输出应为LexToken(EQUALITY,'==',1,0)
,但它为LexToken(ASSIGNMENT,'=',1,0) LexToken(ASSIGNMENT,'=',1,1)
。这似乎是因为词法分析者更喜欢ASSIGNMENT
而不是EQUALITY
- 优先考虑较长的正则表达式而不是较长的匹配。
是否有可能让PLY的词法分子遵循“最大的蒙克”原则?
如果没有,是否有关于如何指定令牌以避免“少于最大咬合”情况(如上述情况)的指导原则?
答案 0 :(得分:2)
PLY使用Python自己的re
包来匹配令牌,方法是将单个正则表达式构建为备选方案的组合。由于python的正则表达式库不是最大的munch,因此也不是PLY。
相反,所选的匹配是这个匹配的大正则表达式中的第一个模式,并且该顺序记录在PLY nanual中:
构建主正则表达式时,将按以下顺序添加规则:
函数定义的所有标记的添加顺序与它们在词法分析器文件中的显示顺序相同。
接下来通过按照正则表达式长度减少的顺序对字符串定义的标记进行排序(首先添加更长的表达式)。
由于匹配=
的模式较长,因此会提前插入,==
无法匹配。
要修复它,请创建模式功能,然后根据需要对其进行排序。