解析器DCG具有不确定性是否合适?

拉乌尔

我正在为查询引擎编写解析器。我的解析器DCGquery不确定。

我将以关系方式使用解析器,以检查和综合查询。

解析器DCG具有不确定性是否合适?

在代码中:

如果我想能够同时使用query / 2,是否要求

?- phrase(query, [q,u,e,r,y]).
true;
false.

还是我应该能够获得

?- phrase(query, [q,u,e,r,y]).
true.

不过,鉴于第一个代码段需要我按原样使用

?- bagof(X, phrase(query, [q,u,e,r,y]), [true]).
true.

使用它检查公式时?

盖伊·编码

要问自己的第一个问题是语法的确定性,或者在语法术语中是明确的这不是在问您的DCG是否是确定性的,而是语法是否明确。可以用基本的解析概念来回答,不需要使用DCG来回答该问题。换句话说,只有一种方法可以解析有效输入。为此的标准书是“编译器:原理,技术和工具”(WorldCat

现在,您实际上正在询问解析的三种不同用途。

  1. 识别器。
  2. 解析器。
  3. 发电机。

如果您的语法是明确的,那么

  1. 对于识别器,答案仅应针对可被解析的有效输入为true,而对于无效输入为false。
  2. 对于解析器,它应该是确定性的,因为只有一种方法可以解析输入。解析器与识别器之间的区别在于,识别器仅返回true或false,而解析器将返回更多内容,通常是抽象语法树。
  3. 对于生成器,它应该是半确定性的,以便可以生成多个结果。

能用DCG做到所有这些吗,是的。三种不同的方式取决于您如何使用DCG的输入和输出。


这是一个非常简单的语法示例。

语法只是带有一个运算符和两个可能的操作数的中缀二进制表达式。运算符为(+),操作数为(1)或(2)。

expr(expr(Operand_1,Operator,Operand_2)) -->
    operand(Operand_1),
    operator(Operator),
    operand(Operand_2).

operand(operand(1)) --> "1".
operand(operand(2)) --> "2".

operator(operator(+)) --> "+".

recognizer(Input) :-
    string_codes(Input,Codes),
    DCG = expr(_),
    phrase(DCG,Codes,[]).

parser(Input,Ast) :-
    string_codes(Input,Codes),
    DCG = expr(Ast),
    phrase(DCG,Codes,[]).

generator(Generated) :-
    DCG = expr(_),
    phrase(DCG,Codes,[]),
    string_codes(Generated,Codes).

:- begin_tests(expr).

recognizer_test_case_success("1+1").
recognizer_test_case_success("1+2").
recognizer_test_case_success("2+1").
recognizer_test_case_success("2+2").

test(recognizer,[ forall(recognizer_test_case_success(Input)) ] ) :-
    recognizer(Input).

recognizer_test_case_fail("2+3").

test(recognizer,[ forall(recognizer_test_case_fail(Input)), fail ] ) :-
    recognizer(Input).

parser_test_case_success("1+1",expr(operand(1),operator(+),operand(1))).
parser_test_case_success("1+2",expr(operand(1),operator(+),operand(2))).
parser_test_case_success("2+1",expr(operand(2),operator(+),operand(1))).
parser_test_case_success("2+2",expr(operand(2),operator(+),operand(2))).

test(parser,[ forall(parser_test_case_success(Input,Expected_ast)) ] ) :-
    parser(Input,Ast),
    assertion( Ast == Expected_ast).

parser_test_case_fail("2+3").

test(parser,[ forall(parser_test_case_fail(Input)), fail ] ) :-
    parser(Input,_).

test(generator,all(Generated == ["1+1","1+2","2+1","2+2"]) ) :-
    generator(Generated).

:- end_tests(expr).

语法是明确的,只有4个有效的字符串,都是唯一的。

识别器是确定性的,仅返回true或false。
解析器是确定性的,并返回唯一的AST。
生成器是半确定性的,并返回所有4个有效的唯一字符串。

测试用例的示例运行。

?- run_tests.
% PL-Unit: expr ........... done
% All 11 tests passed
true.

扩大丹尼尔的评论

丹尼尔(Daniel)指出

1 + 2 + 3 

可以解析为

(1 + 2) + 3 

要么

1 + (2 + 3)

1+2+3正如您所说的is specified by a recursive DCG是一个示例,正如我指出的那样,解决该问题的一种常见方法是使用括号来启动新的上下文。启动新上下文的意思是就像让新的干净表盘重新开始一样。如果要创建AST,则只需将新上下文(位于括号之间的项目)作为新子树放置在当前节点上。

关于write_canonical / 1,这也很有帮助,但请注意运算符的左右关联性。请参阅关联属性

例如

+ 保持联想

?- write_canonical(1+2+3).
+(+(1,2),3)
true.

^ 是正确的联想

?- write_canonical(2^3^4).
^(2,^(3,4))
true.

2^3^4 = 2^(3^4) = 2^81 = 2417851639229258349412352

2^3^4 != (2^3)^4 = 8^4 = 4096

添加此信息的目的是警告您语法设计中充满了隐患,如果您没有严格的课程并完成其中的一些操作,则可以轻松创建看起来不错并且可以正常使用的语法,然后再过几年被发现有严重问题。尽管Python并不是模棱两可的AFAIK,但确实存在语法问题,但它具有足够的问题,以至于在创建Python 3时,许多问题已得到解决。因此,Python 3不与Python 2向后兼容(不同)。是的,他们进行了更改和库编写,以使在Python 3中更轻松地使用Python 2代码,但要点是语法在设计时可以使用更多的分析方法。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章