meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
include [2021/04/01 13:00] – revusky | include [2023/03/03 16:20] (current) – revusky | ||
---|---|---|---|
Line 3: | Line 3: | ||
# The INCLUDE Statement | # The INCLUDE Statement | ||
- | JavaCC 21's **INCLUDE** statement allows you to break up your grammar file into multiple physical files. It would look like this typically: | + | Congo's **INCLUDE** statement allows you to break up your grammar file into multiple physical files. It would look like this typically: |
INCLUDE " | INCLUDE " | ||
Line 17: | Line 17: | ||
In legacy JavaCC, if you defined a token production without specifying a lexical state, any lexical definitions belonged to a lexical state called " | In legacy JavaCC, if you defined a token production without specifying a lexical state, any lexical definitions belonged to a lexical state called " | ||
- | Thus, JavaCC 21 introduces | + | Thus, CongoCC has a setting called **DEFAULT_LEXICAL_STATE**. That means that any lexical specifications where the lexical state is unspecified are in that state. Thus, a JSON grammar would likely have something like this at the top: |
- | DEFAULT_LEXICAL_STATE="JSON"; | + | DEFAULT_LEXICAL_STATE=JSON; |
| | ||
Line 29: | Line 29: | ||
## Wrinkles with Code Injection | ## Wrinkles with Code Injection | ||
- | JavaCC still supports the legacy JavaCC constructs of **PARSER_BEGIN...PARSER_END** and **TOKEN_MGR_DECLS**. (For how much longer, I am not making any promises...). However, those constructs are ignored within an **INCLUDE**d grammar. | + | You can *inject* code into the generated parser or lexer class, from within an included grammar, but you need to write something like: |
- | + | ||
- | You can still *inject* code into the generated parser or lexer class, from within an included grammar, but you need to write something like: | + | |
INJECT PARSER_CLASS : | INJECT PARSER_CLASS : | ||
Line 45: | Line 43: | ||
} | } | ||
- | JavaCC | + | CongoCC |
INJECT JSONParser : | INJECT JSONParser : | ||
Line 52: | Line 50: | ||
} | } | ||
- | because the parser class we are generating is not JSONParser, it is FOOParser! However, the person writing a a generally useful JSON grammar that can be embedded in other grammars does not know the classname of Parser (or Lexer) that is being generated. So, he needs to use the alias **PARSER_CLASS** or possibly **LEXER_CLASS** for the injected code to be included. | + | because the parser class we are generating is not JSONParser, it is FooParser! However, the person writing a a generally useful JSON grammar that can be embedded in other grammars does not know the classname of Parser (or Lexer) that is being generated. So, he needs to use the alias **PARSER_CLASS** or possibly **LEXER_CLASS** for the injected code to be included. |
- | + | ||
- | So, do not be surprised when the code within PARSER_BEGIN...PARSER_END is ignored if it is within an INCLUDEd grammar. You need to write INJECT(PARSER_CLASS) to achieve the desired result. | + | |
In fact, the aliases **PARSER_CLASS**, | In fact, the aliases **PARSER_CLASS**, | ||
- | To see a concrete example of **INCLUDE** in use, you can take a look at https:// | + | To see a concrete example of **INCLUDE** in use, you can take a look at https:// |
</ | </ |