Question

基本要求是使用关键字作为标识符，因此我想区分令牌与其上下文。（例如class是关键字，但我们允许名为class的变量。

在java中，这是可能的，但它很难，here就是这样做的

TOKEN :
{
    <I_CAL:     "CAL">  : DO_CAL
    | <I_CALL:  "CALL">
    | <I_CMP:   "CMP">
    | <I_EXIT:  "EXIT">
    | <I_IN:    "IN">
    | <I_JMP:   "JMP">
    | <I_JPC:   "JPC">  : NEED_CMP_OP
    | <I_LD:    "LD">   : NEED_DATA_TYPE
    | <I_NOP:   "NOP">
    | <I_OUT:   "OUT">
    | <I_POP:   "POP">
    | <I_PUSH:  "PUSH">
    | <I_RET:   "RET">
    | <I_DATA:  "DATA"> : DO_DATA
    | <I_BLOCK:  ".BLOCK">
}

// T prefix for Token
TOKEN :
{
    <T_REGISTER : "R0" | "R1" | "R2" | "R3" | "RP" | "RF" |"RS" | "RB">
// We need below TOKEN in special context, other wise they are just IDENTIFIER
//    | <DATA_TYPE: "DWORD" | "WORD" | "BYTE" | "FLOAT" | "INT">
//    | <PSEUDO_DATA_TYPE: "CHAR" >
//    | <CAL_OP: "ADD" | "SUB" | "MUL" | "DIV" | "MOD">
//    | <CMP_OP: "Z" | "B" | "BE" | "A" | "AE" | "NZ">
    | <T_LABEL: <IDENTIFIER> ([" "])* <COLON>>
}

// Now we need a CMP OP
<NEED_CMP_OP> TOKEN:
{
    <CMP_OP: "Z" | "B" | "BE" | "A" | "AE" | "NZ"> : DEFAULT
}
// Now we need a DATA TYPE
<NEED_DATA_TYPE,DO_CAL> TOKEN:
{
    // EXTENSION Add char to data type
    <DATA_TYPE: "DWORD" | "WORD" | "BYTE" | "FLOAT" | "INT" | "CHAR"> {
        if(curLexState == DO_CAL){
            SwitchTo(NEED_CAL_OP);
        }else{
            SwitchTo(DEFAULT);
        }
    }
}
// We need a CAL OP
<NEED_CAL_OP> TOKEN:
{
    <CAL_OP: "ADD" | "SUB" | "MUL" | "DIV" | "MOD"> : DEFAULT
}
// Aslo need to skip the empty
<NEED_DATA_TYPE,NEED_CAL_OP,NEED_CMP_OP,DO_CAL,DO_DATA> SKIP:
{
    " "
|   "\t"
|   "\r"
|   "\f"
}

来源是here，我可以通过curLexState区分令牌和上下文。

这是有效的，但是做得很挑剔，需要添加很多额外的状态，并保持很多状态。有没有简单的方法来实现这个目标？

Answer 1

如果将词法分析器和解析器合并到面向字符的解析器中，则在上下文中区分关键字相对容易，因为解析器都是关于保留上下文的。您可以在字符令牌上运行JavaCC来实现此效果，但其LL性质可能会因其他原因而无法编写实用语法。

如果你将词法分析器和解析器分开，这并不容易。

您要求词法分析者知道什么是标识符或关键字，它只能通过了解找到Id /关键字的上下文来做到。

理想情况下，词法分析器只会询问解析器的状态，并确定选择的上下文。这很难组织起来;大多数解析器的设计不是为了轻松地显示它们的状态，或者是为了提取所需的上下文信号而易于解释的形式。 JavaCC显然没有这种组织方式。

另一个显而易见的选择是将不同的上下文建模为词法分析器中的状态， lexing状态之间的转换对应于有趣的上下文之间的转换。根据上下文，这可能是也可能不容易。如果你能做到这一点，你必须对词法分析器中的状态和转换进行编码并使它们保持最新。如果你能“轻松”地做到这一点，那就不是一个糟糕的解决方案。根据具体情况，这可能很难或不可能。

对于OP目的（显然是汇编程序的解析器），上下文通常由源代码行中的位置确定。通过观察空白，可以定性地将汇编器输入划分为Label，Opcode，Operand，Comment上下文：换行符将上下文设置为Label，Label模式中的空白将上下文设置为Opcode，Opcode中的空白设置操作数上下文，以及操作数上下文集中的空格上下文。通过这些状态转换，可以为每个上下文编写不同的sublexers，从而在每个子上下文中使用不同的关键字。

这个技巧不适用于像PL / I这样的语言，它们在上下文中有大量关键字（对于PL / I，事实上，每个关键字只在上下文中！）。

一个不明显的选择是不要试图区分。找到ID /关键字后，将两个标记提供给解析器，然后让它找出哪一个导致可行的解析。（注意：它可能已经处理了多个模糊标记的交叉产品，因此在排序时会有很多可能的解析。）这需要一个解析器，它可以解析歧义，无论是在解析时还是在它接受的标记中（或者它不能同时接受ID和关键字令牌）。当您拥有正确的解析机制时，这是一个非常简单的解决方案。 JavaCC不是那种机器。

[请参阅我的bio获取GLR解析引擎，其中所有3种解决方案均可轻松访问。它很容易处理Pl / I.

Answer 2

JavaCC FAQ中列出了三种方法。

一个是使用词汇状态，就像你所做的那样。这种方法可能很棘手，但它是处理最长匹配的长度取决于上下文或跳过规则取决于上下文的情况的唯一方法。对于您的问题，它可能比您需要的更复杂。
第二种是使用一种令牌类型，并使用基于令牌图像的语义预测来使解析器在某些情况下特别处理某些令牌。有关详细信息，请参阅常见问题解答。
第三种（通常也是最简单的）方法是在词汇层面进行区分，然后忽略句法层面的区别。这通常是处理可以兼作标识符的关键字的最佳方式。

下面我将给出第三种方法的三个例子。

使用关键字作为标识符

如果您只想将关键字 class 用作变量名，那么有一种非常简单的方法可以做到这一点。在通常规则中的词法分析器。

TOKEN: { <CLASS: "class"> }
TOKEN: { < VARNAME: ["a-"z","A"-Z"](["a-"z","A"-Z"])* > } // Or what you will

在解析器中编写一个产品

Token varName() { Token t ; } : {
{
    (t = <CLASS> | t = <VARNAME>)
    {return t ;}
}

然后在解析器的其他地方使用varName()。

原始海报的汇编程序

转到原始问题中的汇编程序示例，让我们以JPC指令为例。 JPC（跳转条件）指令后跟一个比较运算符，如Z，B等，然后是一个操作数，可以是许多东西，包括标识符。例如。我们可以

JPC Z fred

但是我们也可以有一个名为JPC或Z的标识符，所以

JPC Z JPC

和

JPC Z Z

也是有效的JPC说明。

在词汇部分我们有

TOKEN : // Opcodes
{
    <I_CAL: "CAL"> 
|   <I_JPC: "JPC"> 
|   ... // other op codes
    <CMP_OP: "Z" | "B" | "BE" | "A" | "AE" | "NZ">
|   <T_REGISTER : "R0" | "R1" | "R2" | "R3" | "RP" | "RF" |"RS" | "RB">
}
... // Other lexical rules.

TOKEN : // Be sure this rule comes after all keywords.
{
    < IDENTIFIER: <LETTER> (<LETTER>|<DIGIT>)* >
}

在解析器中我们有

Instruction Instruction():{
    Instruction inst = new Instruction();
    Token o = null,dataType = null,calType = null,cmpType = null;
    Operand a = null,b = null; }
{
    ...
    o = <I_JPC> cmpType = <CMP_OP> a = Operand()
    ...
}

Operand Operand():{
    Token t ; ... }
{
     t = <T_REGISTER> ...
|    t = Identifier()  ...
    ...
}

Token Identifier : {
    Token t ; }
{
    t = <IDENTIFIER> {return t ;}
|   t = <I_CAL>      {return t ;}
|   t = <I_JPC>      {return t ;}
|   t = <CMP_OP>     {return t ;}
| ... // All other keywords
}

我建议从其他可用作标识符的关键字列表中排除注册名称。

如果你在该列表中包含<T_REGISTER>，则操作数会出现歧义，因为Operand看起来像这样

Operand Operand():{
    Token t ; ... }
{
     t = <T_REGISTER> ...
|    t = Identifier()  ...
    ...
}

现在存在歧义，因为

JPC Z R0

有两个解析。在作为操作数的上下文中，我们想要诸如＆＃34; R0＆＃34;被解析为寄存器而不是标识符。幸运的是，JavaCC更喜欢早先的选择，所以这就是将要发生的事情。您将收到来自JavaCC的警告。您可以忽略该警告。（我在源代码中添加了注释，以便其他程序员不必担心。）或者您可以使用先行规范来抑制警告。

Operand Operand():{
    Token t ; ... }
{
     LOOKAHEAD(1) t = <T_REGISTER> ...
|    t = Identifier()  ...
    ...
}

使用正确的上下文

到目前为止，所有示例都使用了左上下文。即我们可以告诉如何仅根据左侧令牌的顺序来处理令牌。让我们看一下关键字的解释是基于右边的标记的情况。

考虑这种简单的命令式语言，其中所有关键字都可以用作变量名。

P -> Block <EOF>
Block -> [S Block]
S -> Assignment | IfElse
Assignment -> LHS ":=" Exp
LHS -> VarName
IfElse -> "if" Exp Block ["else" Block] "end"
Exp -> VarName
VarName -> <ID> | if | else | end

这个语法是明确的。您可以通过添加新类型的语句，表达式和左侧来使语法更复杂;只要语法保持明确，这些并发症可能不会对我接下来要说的内容产生很大的影响。随意尝试。

语法不是LL（1）。有两个地方必须根据多个未来令牌进行选择。一个是Assignment和IfElse之间的选择，当下一个标记是＆＃34;如果＆＃34;。考虑块

a := b
if := a

VS

a := b
if q
    b := c
end

我们可以展望＆＃34;：=＆＃34;像这样

void S() : {} {
    LOOKAHEAD( LHS() ":=" ) Assignment()
|
    IfElse() 
}

我们需要展望的另一个地方是＆＃34; else＆＃34;或者＆＃34;结束＆＃34;在块的开头遇到。考虑

if x
    end := y
    else := z
end

我们可以用

来解决这个问题

void Block() : {} {
    LOOKAHEAD( LHS() ":=" | "if" ) S() Block()
|
    {}
}

JavaCC可以通过其上下文区分令牌吗？

2 个答案:

使用关键字作为标识符

原始海报的汇编程序

使用正确的上下文