groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: More Antlr4-based Groovy parser status update
Date Fri, 11 Mar 2016 10:11:50 GMT
By the way, I had a question (unrelated to the below thread, but related to
the grammar) :-)

Do you keep the comment information?
It's something we've always said we should support, and it would
tremendously help making a less hackish groovydoc tool.
Having AST nodes for JavaDoc comments would really be great.

Guillaume

On Sun, Feb 28, 2016 at 12:55 PM, Jesper Steen Møller <jesper@selskabet.org>
wrote:

> 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://jespersm@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
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet <http://restlet.com>

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Mime
View raw message