【问题标题】:How do underivable rules affect parsing?可求值规则如何影响解析?
【发布时间】:2018-04-27 17:30:27
【问题描述】:

在为简单的 SQL 方言编写 XText 语法时,我发现,显然不能从开始符号派生的规则会影响解析。

例如鉴于我的语法的以下(非常简化的)摘录应该能够解析像FROM table1;这样的表达式:

Start:
    subquery ';';  

subquery:
    /*select=select_clause */tables=from_clause;

from_clause:
    'FROM' tables;

tables:
    tables+=table (',' tables+=table)*;

table:
    name=table_name (alias=alias)?;

table_name: 
    prefix=qualified_name_prefix? name=qualified_name;

qualified_name_prefix:
    ID'.';

qualified_name :
    =>qualified_name_prefix? ID;

alias returns EString:
    'AS'? alias=ID;

with_clause : 
    'WITH' elements+=with_list_element (',' elements+=with_list_element)*;

with_list_element : 
     name=ID (column_list_clause=column_list_clause)? 'AS' '(' subquery=subquery ')';

column_list_clause : 
    '(' names+=ID+ ')';

尝试解析字符串FROM table1;时,出现以下错误:

'在 EString 上的输入 ';'' 处没有可行的替代方案

如果我删除规则with_clause,错误就会消失并且字符串会被正确解析。即使with_clause 不能从Start 派生,这怎么可能?

【问题讨论】:

    标签: parsing xtext


    【解决方案1】:

    问题在于谓词 (=>) 包含歧义

    也许你可以把前缀和名字放在一起

    Table_name: 
         name=Qualified_name;
    
    Qualified_name :
       (ID '.' (ID '.')?)? ID;
    

    或者你尝试类似的东西

    Table_name: 
        ((prefix=ID ".")? =>name=Qualified_name);
    
    Qualified_name :
       =>(ID '.' ID) | ID;
    

    【讨论】:

    • 前者确实解决了我的语法问题。坦克很多。但是,这并不能回答为什么删除不可求值规则允许正确解析输入的问题。你知道为什么会这样吗?
    • 我认为这些规则在解析器的某个地方被使用了
    猜你喜欢
    • 2013-05-23
    • 2011-02-05
    • 1970-01-01
    • 1970-01-01
    • 2019-03-06
    • 1970-01-01
    • 2020-04-05
    • 1970-01-01
    • 2022-01-17
    相关资源
    最近更新 更多