[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [antlr-interest] Re: antlr vs. sableCC comparison

Hi DM,

I do not intend to personally send a reply to that forum, and
I have little time to waste on frivolous flamewars, but I can
point out a few errors in the claims below.

dm@cs.yorku.ca wrote:
----- Forwarded message from lgcraymer <lgc@mail1.jpl.nasa.gov> -----
    Date: Sat, 24 May 2003 05:47:42 -0000
    From: lgcraymer <lgc@mail1.jpl.nasa.gov>
Reply-To: antlr-interest@yahoogroups.com
 Subject: [antlr-interest] Re: antlr vs. sableCC comparison
      To: antlr-interest@yahoogroups.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.

There are four important missing features above (for SableCC 2.x): 4) Strictly-typed heterogeneous AST 5) Name-based access to children node (intead of error-prone index-based access) 6) Complete separation of users written code and generated code, allowing direct debugging of user written code, and a shorter development cycle for compilers and interpreters. 7) Overall very intuitive syntax and overall framework.

These four last point were at the heart of my M.Sc. thesis.  DFA, LALR(1)
and visitors were only the base tools I used to illustrate these concepts.

Of course, upcoming SableCC versions will add many additional features.
For example, SableCC 3.0.0 brings a innovative mechanism to intuitively
specify concrete syntax tree (CST) to abstract syntax tree (AST)
parse-time transformations in the grammar.  This mechanism goes well
beyond "getting rid of unneeded tokens", and is subject to full semantic
verifications (so, there's no way to specify invalid transformations).
The mechanism is deterministic; it does not depend on "pattern matching"
(whose result could vary depending on the pattern search order).

Predicated LL(k) (ANTLR) parsing can handle any context-free grammar,

This is a misleading statement. I will not enter this debate. Either the poster is clueless, either he simply wants to provoke a flamewar.

Please note my use of the word "misleading", and not "false".  The
problem has to do with the meaning of "can handle".

ANTLR's tree grammar approach is more powerful than the visitor approach. In fact, a visitor can be expressed as a special ANTLR tree (I've not tested this code, but it should work):

I have great admiration for Terrence Parr's Ph.D. research and his ANTLR software. I will not get into arguments about which software is better. SableCC and ANTLR have both some advantages over the other. You simply need to pick the right tool for a given task.


Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/