meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
include [2020/12/18 08:40] revuskyinclude [2021/04/01 13:00] revusky
Line 5: Line 5:
 JavaCC 21's **INCLUDE** statement allows you to break up your grammar file into multiple physical files. It would look like this typically: JavaCC 21's **INCLUDE** statement allows you to break up your grammar file into multiple physical files. It would look like this typically:
  
-   INCLUDE("IncludedGrammar.javacc")+    INCLUDE "IncludedGrammar.javacc"
  
 *This feature is not present in legacy JavaCC.* *This feature is not present in legacy JavaCC.*
Line 25: Line 25:
 In that case, any grammar for a language that wants to handle embedded JSON data would presumably define its own "default" lexical state, and when it wants to embedded JSON data, would have to make an explicit switch to that JSON lexical state that is the *default* in the included grammar. In that case, any grammar for a language that wants to handle embedded JSON data would presumably define its own "default" lexical state, and when it wants to embedded JSON data, would have to make an explicit switch to that JSON lexical state that is the *default* in the included grammar.
  
-Actually, a t the moment, **DEFAULT_LEXICAL_STATE** is the only setting you can put in an **INCLUDE**d grammar that has any effect. All of the other options are simply ignored, since they are presumably set in the top-level *including* grammar. In legacy JavaCC, if you defined a token production without specifying a lexical state, those patterns are matched in a lexical state called "DEFAULT" -- by default, obviously. This is a problem in terms of its interaction with the INCLUDE directive, since both grammars are liable to have a "DEFAULT" lexical state. So, you see, the solution is that the *default* lexical state (the one you are using if none is explicitly specified) should be different in the *including* grammar from the *included* one.+Actually, at the moment, **DEFAULT_LEXICAL_STATE** is the only setting you can put in an **INCLUDE**d grammar that has any effect. All of the other options are simply ignored, since they are presumably set in the top-level *including* grammar. In legacy JavaCC, if you defined a token production without specifying a lexical state, those patterns are matched in a lexical state called "DEFAULT" -- by default, obviously. This is a problem in terms of its interaction with the INCLUDE directive, since both grammars are liable to have a "DEFAULT" lexical state. So, you see, the solution is that the *default* lexical state (the one you are using if none is explicitly specified) should be different in the *including* grammar from the *included* one.
  
 ## Wrinkles with Code Injection ## Wrinkles with Code Injection
Line 33: Line 33:
 You can still *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 40: Line 40:
 or: or:
  
-    INJECT(**LEXER_CLASS**) +    INJECT LEXER_CLASS : 
     {     {
        ...        ...
Line 47: Line 47:
 JavaCC 21 will replace the **PARSER_CLASS** and **LEXER_CLASS** aliases with the appropriate names -- i.e. the actual class names of the XXXParser or XXXLexer being generated. So, if you have a Foo language in which you want to embed JSON expressions, so you include a JSON grammar, if that JSON grammar is to include some code within the generated parser, it cannot be: JavaCC 21 will replace the **PARSER_CLASS** and **LEXER_CLASS** aliases with the appropriate names -- i.e. the actual class names of the XXXParser or XXXLexer being generated. So, if you have a Foo language in which you want to embed JSON expressions, so you include a JSON grammar, if that JSON grammar is to include some code within the generated parser, it cannot be:
  
-    INJECT(JSONParser:+    INJECT JSONParser :
     {     {
        ...        ...
Line 67: Line 67:
 to only contain Java source code. Thus, writing: to only contain Java source code. Thus, writing:
  
-   INCLUDE("SomeJavaCode.java")+   INCLUDE "SomeJavaCode.java"
        
 is exactly the same as if you wrote: is exactly the same as if you wrote: