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 [2020/02/09 19:25] – 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. | + | Congo's **INCLUDE** statement allows you to break up your grammar file into multiple physical files. |
- | The motivation behind INCLUDE should be fairly | + | INCLUDE " |
+ | |||
+ | *This feature is not present in legacy JavaCC.* | ||
+ | |||
+ | The motivation behind | ||
Still, as they say, the devil is in the details, and there are some various wrinkles that need to be covered here. | Still, as they say, the devil is in the details, and there are some various wrinkles that need to be covered here. | ||
Line 11: | Line 15: | ||
## The DEFAULT_LEXICAL_STATE setting | ## The DEFAULT_LEXICAL_STATE setting | ||
- | In legacy JavaCC, if you defined a token production without specifying a lexical state, any lexical definitions | + | In legacy JavaCC, if you defined a token production without specifying a lexical state, any lexical definitions |
- | 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; | ||
- | options { | ||
- | | ||
- | } | ||
| | ||
- | at the top. In that case, any grammar for a language that wants to handle embedded JSON data would presumably define | + | In that case, any grammar for a language that wants to handle embedded JSON data would presumably define |
- | At the moment, **DEFAULT_LEXICAL_STATE** is the only setting you can put in an INCLUDEd | + | Actually, at the moment, **DEFAULT_LEXICAL_STATE** is the only setting you can put in an **INCLUDE**d |
## 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 |
- | If you want to *inject* code into the generated parser or lexer class, from within an included grammar, you need to write something like: | + | |
- | + | ||
- | | + | |
- | { | + | |
- | ... | + | |
- | } | + | |
{ | { | ||
... | ... | ||
Line 39: | 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 JSON grammar | + | because the parser class we are generating is not JSONParser, it is FooParser! However, the person writing a a generally useful |
- | So, do not be surprised when the code within PARSER_BEGIN...PARSER_END is ignored if it is within | + | In fact, the aliases **PARSER_CLASS**, |
- | In fact, the aliases | + | 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:// | + | </ |
+ | |||
+ | ===== INCLUDE | ||
+ | |||
+ | Note also that if the name of the INCLUDEd file ends in .java or in .jav, then the the file is assumed | ||
+ | to only contain | ||
+ | |||
+ | | ||
+ | |||
+ | is exactly the same as if you wrote: | ||
+ | |||
+ | INJECT : { | ||
+ | | ||
+ | } | ||
+ | |||
+ | In other words, it is equivalent to the second sort of code injection described [[code_injection_in_javacc_21## | ||
- | </ | ||