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/02/05 21:35] – 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(" | + | |
*This feature is not present in legacy JavaCC.* | *This feature is not present in legacy JavaCC.* | ||
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; |
| | ||
In that case, any grammar for a language that wants to handle embedded JSON data would presumably define its own " | In that case, any grammar for a language that wants to handle embedded JSON data would presumably define its own " | ||
- | Actually, | + | Actually, |
## 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 | + | You can |
- | You can still *inject* code into the generated parser or lexer class, from within an included grammar, but you need to write something like: | + | |
- | + | ||
- | | + | |
{ | { | ||
... | ... | ||
Line 40: | Line 38: | ||
or: | or: | ||
- | INJECT(LEXER_CLASS) : | + | INJECT LEXER_CLASS : |
{ | { | ||
... | ... | ||
} | } | ||
- | JavaCC | + | CongoCC |
- | INJECT(JSONParser) : | + | INJECT JSONParser : |
{ | { | ||
... | ... | ||
} | } | ||
- | 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:// |
</ | </ | ||
Line 67: | Line 63: | ||
to only contain Java source code. Thus, writing: | to only contain Java source code. Thus, writing: | ||
- | | + | |
is exactly the same as if you wrote: | is exactly the same as if you wrote: |