Проблема синтаксиса JavaCC с пониманием способности - PullRequest
Новая
       37

Проблема синтаксиса JavaCC с пониманием способности

0 голосов
/ 30 октября 2019

Я начинаю изучать Javacc и пытаюсь разобраться в этой проблеме, но я не могу полностью понять, правильно ли я это делаю или нет.

Итак, я делаю парсер для пользовательского языка и генерирую исходный код парсера Java с использованием Javacc.

Я думаю, что я делаю это правильно, но у меня много сомнений в том,правильно или нет. Мы будем благодарны за любую помощь и за любые советы о том, что правильно, а что нет.

Вот файл .jj, который у меня есть. 

options {
  JAVA_UNICODE_ESCAPE = true;
  STATIC = false;
}

PARSER_BEGIN(Custom_Lexer)
  public class Custom_Lexer {}
PARSER_END(Custom_Lexer)


void Custom_Lexer_Program() :
{}
{
  <BEGIN> <CLPL>
  ( Custom_Lexer_Statement() )*
  <END>
  <EOF>
}

void Custom_Lexer_Statement():
{}
{
    STATEMENT()
    <SEMICOLON>
}

void STATEMENT():
{}
{
    LOOKAHEAD(2) OUTPUT_STATEMENT()     |
    LOOKAHEAD(2) INPUT_STATEMENT()      |
    LOOKAHEAD(2) VARIABLE_DECLARATION() | 
    LOOKAHEAD(2) VARIABLE_ASSIGNMENT()  |
    LOOKAHEAD(2) IF_THEN_STATEMENT()
}

void OUTPUT_STATEMENT():
{}
{
    <OUTPUT> <EQUALS> EXPRESSION()
}

void INPUT_STATEMENT():
{}
{
    VARIABLE_DECLARATION()*
}

void VARIABLE_DECLARATION():
{}
{
    <VARIABLE> (<EQUALS> <INT> | <BOOL> | <STRING>)?
}

void VARIABLE_ASSIGNMENT():
{}
{
    <VARIABLE> (<EQUALS> EXPRESSION()
}

void IF_THEN_STATEMENT():
{}
{
    <IF> EXPRESSION() <THEN> VARIABLE_ASSIGNMENT() [<ELSE> VARIABLE_ASSIGNMENT()]
}
//Will define these later after the above issues are fixed
void EXPRESSION():
{}
{
    LOOKAHEAD(5) BINARY_EXPRESSION()        |
    LOOKAHEAD(5) IDENTIFIER_EXPRESSION()    |
    LOOKAHEAD(5) LITERAL_VALUE_EXPRESSION() |
    LOOKAHEAD(5) PARENTHESIZED_EXPRESSION()
}


//Reserved words
TOKEN: { <CLPL:   "CLPL"   > }
TOKEN: { <BEGIN:   "BEGIN"   > }
TOKEN: { <END:     "END"     > }
TOKEN: { <OUTPUT:  "OUTPUT"  > }
TOKEN: { <INPUT:   "INPUT"   > }
TOKEN: { <IF:      "IF"      > }
TOKEN: { <THEN:    "THEN"    > }


TOKEN: { <INT:    "int"      > }
TOKEN: { <BOOL:   "bool"     > }
TOKEN: { <STRING: "string"   > }


TOKEN: { <SEMICOLON:     ";" > }
TOKEN: { <LEFT_PAREN:    "(" > }
TOKEN: { <RIGHT_PAREN:   ")" > }
TOKEN: { <PLUS:          "+" > }
TOKEN: { <MINUS:         "-" > }
TOKEN: { <MULTIPLY:      "*" > }
TOKEN: { <DIVIDE:        "/" > }
TOKEN: { <EQUALITY:     "==" > }
TOKEN: { <EQUALS:        "=" > }
TOKEN: { <GT:            ">" > }
TOKEN: { <LT:            "<" > }


TOKEN: { <BOOLEAN_LITERAL: "true" | "false" > }


TOKEN: { <INTEGER_LITERAL: (["0"-"9"])+ > }


TOKEN: { <STRING_LITERAL: "\"" (~["\"","\\","\n","\r"] | "\\" (["n","t","b","r","f","\\","\'","\""] | ["0"-"7"] (["0"-"7"])? | ["0"-"3"] ["0"-"7"] ["0"-"7"]))* "\""> }


TOKEN: { <IDENTIFIER: (["a"-"z"]|["A"-"Z"]|"_")+((["a"-"z","A"-"Z","0"-"9","_"])*)? > }

1 Ответ

1 голос
/ 31 октября 2019

Это незаконченное, но выглядит разумным началом. Я бы посоветовал вам избегать всех LOOKAHEAD спецификаций, пока вы не поймете, что делаете лучше. Попробуйте использовать факторинг слева, чтобы все варианты можно было сделать с помощью метода просмотра по умолчанию.

Одна проблема, которую я вижу, заключается в том, что конфликт между VARIABLE_DECLARATION и INPUT_STATEMENT не может быть разрешен, поскольку любой VARIABLE_DECLARATION такжеINPUT_STATEMENT.

...