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
key_differences [2020/12/12 23:28] – [JavaCC 21 is being actively developed] revuskykey_differences [2023/07/08 07:25] (current) revusky
Line 1: Line 1:
-====== Key Differences between JavaCC 21 and Legacy JavaCC ======+====== Key Differences between CongoCC and Legacy JavaCC ======
  
-From the end user's point of view, the most important difference is that JavaCC 21 has undergone quite a bit of re-design to make it much more usable "out of the box" than the legacy JavaCC. One of the most basic (and obvious) things that JavaCC 21 provides is the [[INCLUDE]] statement. With legacy JavaCC, the only way to reuse commonly used constructs across different grammars was via the classic copy-paste //antipattern//.+From the end user's point of view, the most important difference is that CongoCC has undergone quite a bit of re-design to make it much more usable "out of the box" than the legacy JavaCC. One of the most basic (and obvious) things that CongoCC provides is the [[INCLUDE]] statement. With legacy JavaCC, the only way to reuse commonly used constructs across different grammars was via the classic copy-paste //antipattern//.
  
 There has been an effort to clean up the set of configuration options. In general, the philosophy of JavaCC 21 is to make configuration options largely unnecessary, at least for typical usage, since the defaults are set sensibly and, in the absence of configuration settings, the tool simply infers naming via conventions. See [[convention over configuration]] for more information. There has been an effort to clean up the set of configuration options. In general, the philosophy of JavaCC 21 is to make configuration options largely unnecessary, at least for typical usage, since the defaults are set sensibly and, in the absence of configuration settings, the tool simply infers naming via conventions. See [[convention over configuration]] for more information.
Line 7: Line 7:
 It seems quite clear that building an AST [[Abstract Syntax Tree]] is the most typical use case for this sort of tool. So, there has been a heavy focus on making the whole thing much simpler. In legacy JavaCC, generating a parser that builds an AST is actually a rather baroque build process. You write a grammar with special "tree-buildling annotations" that you process with the legacy JJTree tool, which is really a //pre-processor// that in turn generates a JavaCC grammar. Then you run JavaCC on that to generate your Java source code. It seems quite clear that building an AST [[Abstract Syntax Tree]] is the most typical use case for this sort of tool. So, there has been a heavy focus on making the whole thing much simpler. In legacy JavaCC, generating a parser that builds an AST is actually a rather baroque build process. You write a grammar with special "tree-buildling annotations" that you process with the legacy JJTree tool, which is really a //pre-processor// that in turn generates a JavaCC grammar. Then you run JavaCC on that to generate your Java source code.
  
-With JavaCC 21, the JJTree pre-processor functionality is merged into the JavaCC tool and, even in the absence of special tree-building annotations (though they are still supported) the generated parser simply builds an AST by default, following some common-sense conventions. (N.B. You can still generate a parser that does not automatically build an AST, but you need to specify that via TREE_BUILDING_ENABLED=false in the settings.)+With Congo, the JJTree pre-processor functionality is merged into the JavaCC tool and, even in the absence of special tree-building annotations (though they are still supported) the generated parser simply builds an AST by default, following some common-sense conventions. (N.B. You can still generate a parser that does not automatically build an AST, but you need to specify that via TREE_BUILDING_ENABLED=false in the settings.)
  
 ===== Tree Building Enhancements ===== ===== Tree Building Enhancements =====
Line 15: Line 15:
 ===== Code Injection ===== ===== Code Injection =====
  
-JavaCC 21 introduces a new statement called **INJECT** that allows you to "inject" code into the files that the tool generates. This can help you to avoid the error-prone anti-pattern of generating code and editing it afterwards. See [[Code Injection in JavaCC 21]] for more information.+CongoCC introduces a new statement called **INJECT** that allows you to "inject" code into the files that the tool generates. This can help you to avoid the error-prone anti-pattern of generating code and editing it afterwards. See [[Code Injection in JavaCC 21]] for more information.
  
 ===== Streamlined Syntax ===== ===== Streamlined Syntax =====
  
-JavaCC 21 incorporates an [[new syntax summary|alternative streamlined syntax]] that should be quite a bit more pleasant to write and easier to read.+CongoCC incorporates an [[new syntax summary|alternative streamlined syntax]] that should be quite a bit more pleasant to write and easier to read.
  
 The difference is frequently dramatic. Where the legacy tool required you to write things like: The difference is frequently dramatic. Where the legacy tool required you to write things like:
Line 27: Line 27:
 </code> </code>
  
-in JavaCC 21 you could express the above as:+in CongoCC you could express the above as:
  
 <code> <code>
Line 37: Line 37:
 Perhaps most importantly, the longstanding bug of nested syntactic lookahead not working correctly has [[https://javacc.com/2020/07/15/nested-syntactic-lookahead-works/|finally been squashed]]! Perhaps most importantly, the longstanding bug of nested syntactic lookahead not working correctly has [[https://javacc.com/2020/07/15/nested-syntactic-lookahead-works/|finally been squashed]]!
  
-The ''SCAN'' construct (designed to supersede the legacy ''LOOKAHEAD'') offers a superset of the legacy ''LOOKAHEAD'' functionality. [[Lookbehind]] predicates allow you to define conditions at [[choice points]] based on scanning backwards in the parse/lookahead stack. [[Lookbehind]] also works in arbitrarily nested scanahead.+The ''SCAN'' construct (designed to supersede the legacy ''LOOKAHEAD'') offers a superset of the legacy ''LOOKAHEAD'' functionality. [[contextual_predicates]] predicates allow you to define conditions at [[choice points]] based on scanning backwards in the parse/lookahead stack. [[contextual_predicates]] also works in arbitrarily nested scanahead.
  
 The new [[up to here]] construct should eliminate the need to write more verbose and error-prone numerical and syntactic lookahead constructs.  The new [[up to here]] construct should eliminate the need to write more verbose and error-prone numerical and syntactic lookahead constructs. 
Line 44: Line 44:
  
  
-===== JavaCC 21 is being actively developed =====+===== CongoCC is being actively developed =====
  
-JavaCC 21 now supports the full Java language up through Java 15. Since the [[https://github.com/javacc21/javacc21/blob/master/src/main/grammars/Java.javacc|Java grammar]] is embedded in [[https://github.com/javacc21/javacc21/blob/master/src/main/grammars/JavaCC.javacc#L413|JavaCC grammar]] using the [[INCLUDE]] mechanism, that Java grammar is usable on its own. Note that this grammar successfully parses all the Java source code in the OpenJDK 15, as well as all the Java source code in JRuby, Jython, and FreeMarker. So, if anybody needs a Java code parser for use in their own projects, this is quite usable! +CongoCC now supports the full Java language up through Java 19. Since the [[https://github.com/congo-cc/congo-parser-generator/blob/main/examples/java/Java.ccc|Java grammar]] is embedded in [[https://github.com/congo-cc/congo-parser-generator/blob/main/src/grammars/CongoCC.ccc#L445|CongoCC grammar]] using the [[INCLUDE]] mechanism, that Java grammar is usable on its own. Note that this grammar successfully parses all the Java source code in the OpenJDK 20, as well as all the Java source code in JRuby, Jython, and FreeMarker. So, if anybody needs a Java code parser for use in their own projects, this is quite usable!