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

Re: SableCC vs. Antlr?

Kyle F. Downey writes:
 > I looked at both when making my decision for a compiler-compiler.
 > The biggest difference in my mind is that SableCC does all the
 > node and tree-walking code generation for you, will the other CC's
 > do not. This enabled SableCC to cleanly split the grammar definition
 > from the Java source code, so the two are not intermingled.
I used Antlr in a medium sized project with some smaller /*i.e. 30..70
rules*/ parsers, where some of them inherit features of existing
parsers and unfortunately, I had a closer look at SableCC a month too
[--- text follows this line ---]
My point of view is now the following:
  - I agree, that the underlying visitor pattern [of SableCC] leads to
    a much cleaner overall design.  You should be able to apply true
    object-oriented subclassing to node classes.  This is impossible
    with antlr; see below.  Especially, you get a very clear picture of
    parsing as a process of object deserialisation.  See 


    for some considerations on that.
    Also, SableCC's view adopts very much an ontological perspective,
    since non-terminals are close to an understanding of being entities
    and not processes, transformations or events, what would be the
    analogon for a method as used in Antlr.

  - it's often not easy to write understandable LL(k) grammars

  - antlr parsers are pretty robust after stumbling over a syntax error 

  - with antlr file dependencies are not easily to be detected
    automatically, i.e. you don't have easy walking, if you want to
    write a makefile. 

 > > Hi again,
 > >
 > > How does SableCC compareto Antlr?

Antlr uses methods [of one large parser class] to represent
non-terminals in grammar rules, while SableCC represents non-terminals
as classes. 

 > > Features of SableCC that is not in Antlr?
 > > Vice versa?

Antlr has an LL(k) scanner.

 > > Benefits of using SableCC?

It is near to, how an object oriented parser should be.  All other [, to my
knowledge,] authors of OO parser generators still think too much in
terms of lex and yacc.