Hi Pascal, Thank you, I’d missed that one.
Any thought on the validity of “- -1”? -Jesper > On 28. feb. 2016, at 18.23, Pascal Schumacher <pascalschumac...@gmx.net > <mailto:pascalschumac...@gmx.net>> wrote: > > Hi Jesper, > > thanks for the update. :) Nice to hear you are progressing. > > Concerning the ASTBuilder to Java conversion, there is a pull request with > this at the old repo https://github.com/groovy/groovy-core/pull/513 > <https://github.com/groovy/groovy-core/pull/513> > > Cheers, > Pascal > > Am 28.02.2016 um 12:55 schrieb Jesper Steen Møller: >> Hi Groovy-Dev >> >> Here’s another update on the progress on the Antlr4 parser, as maintained on >> https://github.com/jespersm/groovy.git >> <https://github.com/jespersm/groovy.git> (in the antlr4 branch). >> To play with it, try: >> >> $ git clone -b antlr4 https://jespe...@github.com/jespersm/groovy.git >> <https://jespe...@github.com/jespersm/groovy.git> >> $ cd groovy >> $ gradle -PuseAntlr4=true console >> >> I’ve fixed a number of issues: >> Support method pointer operator >> Attributes/method/property names as strings/gstrings >> Real support for unary plus and minus (mimics old parser’s behaviour) >> Compilation units not ending with semicolon or newline >> Slashy strings could span lines, confusing division statements and comments >> I can now explore the new grammar and AST building using the Console, which >> is fun, but it’s very easy to find unsupported constructs. Mapping out the >> full Groovy grammar from the documentation alone is quite a task. Just >> today, I discovered lacking support for ‘assert’ and for ’super’-calls. The >> smaller issues currently are: >> assert >> super() >> Full Unicode letter support for identifiers >> Support identifiers as property names and map literal entry names >> >> The bigger issue is with converting the ASTBuilder to pure Java, a task I >> havn’t started yet. Actually, this poses a different question for AST >> generation: Whether to switch from tree-walking the parse tree (so whole >> tree must be kept in memory), to the listener-based approach, where the AST >> is built mostly bottom-up, ensuring smaller memory footprint. >> >> So you can help me with a couple of answers: >> Memory: Is this an issue I should be focusing on — and is there a test to >> baseline against? >> I’ve discovered a small issue with unary syntax. Currently, nested unary >> expressions are not supported without parenthesis: Try e.g. - -1 or + -1. Is >> this intentional, or just an artifact of the precedence-refactored Java >> grammar? >> >> -Jesper >> >
