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 20: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. | + | 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 who wants it to be included does not know the name of the class. 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 | + | because |
- | 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 72: | 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: |