groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wagenleitner <john.wagenleit...@gmail.com>
Subject Re: making parser modules for antlr2 and antlr4
Date Tue, 25 Oct 2016 21:36:59 GMT
On Tue, Oct 25, 2016 at 1:53 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> Hi,
>
> 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?
>
>

Could the existing "org.codehaus.groovy.syntax.TokenMismatchException"
cover the cases for "NoViableAltException" and "MismatchedTokenException"
(or maybe all cases since the focus is on finding unexpected EOF)?

Mime
View raw message