[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [antlr-interest] Re: antlr vs. sableCC comparison
I have a pragmatic answer to Loring's question:
For our company, the chief advantage of SableCC over Antlr was that SableCC
generated all of the required lexer and parser code and didn't require that
we included the SableCC class library in with our application. This was
quite important because we were developing a spreadsheet program for
low-bandwidth mobile devices and the distribution had to be tiny <128Kb.
I know that it's possible to use a tool like Proguard to remove redundant
classes from a distribution and thus reduce the size, but when we tried this
with Antlr we were still faced with a 46K overhead compared with the 13.5K
overhead of SableCC's generated code. Besides, surely code generators should
not limit themselves to generating customised extensions of their library?
In that case, the tool isn't outputting independent code it's just
outputting a configuration file.
----- Original Message -----
From: Dave Makalsky <email@example.com>
Sent: Saturday, May 24, 2003 7:55 PM
Subject: Fwd: [antlr-interest] Re: antlr vs. sableCC comparison
> I think someone needs to fire one back at the ANTLR crowd!
> ----- Forwarded message from lgcraymer <firstname.lastname@example.org> -----
> Date: Sat, 24 May 2003 05:47:42 -0000
> From: lgcraymer <email@example.com>
> Reply-To: firstname.lastname@example.org
> Subject: [antlr-interest] Re: antlr vs. sableCC comparison
> To: email@example.com
> My reaction to SableCC has always been, "Why?", and the answer
> always seems to be "it was a good excuse for Gagnon to have fun
> writing a master's thesis". It has less functionality than either
> ANTLR or JavaCC and was introduced after both were available. The
> basic features of SableCC are
> 1.) DFA lexing
> 2.) LALR(1) parsing
> 3.) Visitor-based tree walkers.
> and the package made no real additions to the state-of-the-art, as
> far as I can tell.