groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject making parser modules for antlr2 and antlr4
Date Tue, 25 Oct 2016 20:53:34 GMT

I am looking a bit into the usage of our old parser and keeping in mind 
the new parser we want to eventually make the default.

But one problem I talked about in the past already is the direct usage 
of antlr2 types in something else than the parser itself. Moving the 
current parser into a subproject has the nice effect of highlighting 
those problems, since anltr2 classes are then not automatically part of 
the main module anymore.

And then you find things like this:

>                 if (cause instanceof NoViableAltException) {
>                     return isEofToken(((NoViableAltException) cause).token);
>                 } else if (cause instanceof NoViableAltForCharException) {
>                     char badChar = ((NoViableAltForCharException) cause).foundChar;
>                     return badChar == CharScanner.EOF_CHAR;
>                 } else if (cause instanceof MismatchedCharException) {
>                     char badChar = (char) ((MismatchedCharException) cause).foundChar;
>                     return badChar == CharScanner.EOF_CHAR;
>                 } else if (cause instanceof MismatchedTokenException) {
>                     return isEofToken(((MismatchedTokenException) cause).token);
>                 }

The cause is from a SyntaxErrorMessage (actually cause is the cause of 
the cause). Basically this tells me we are lacking the capability to 
handle this case with only groovy-core classes. For the sake of 
compatibility I donĀ“t think we should get rid of the cause, but extend 
SyntaxError(Message) or SyntaxException to support the transport of the 
missing information.

I could now try to make a single class to cover all of the cases above, 
which means a token (maybe expecting) and foundChar (maybe expectedChar) 
and the problem, that if I have a token I do not have a char and vice 
versa. I could work with Char...

if I want to project the given case and use the classic subclassing 
approach I would produce two new subclasses of SyntaxException. If I 
wanted to support the expected token or char, it would be 4 classes.

Any opinions on that?

bye Jochen

View raw message