Re: Technical arguments for using compiler tools?

parrt@ecn.purdue.edu (Terence J Parr)
Sat, 12 Jun 1993 19:47:40 GMT

          From comp.compilers

Related articles
Technical arguments for using compiler tools? swen09d2@cl2.cl.uh.edu (1993-06-09)
Re: Technical arguments for using compiler tools? markh@csd4.csd.uwm.edu (1993-06-11)
Re: Technical arguments for using compiler tools? parrt@ecn.purdue.edu (1993-06-12)
| List of all articles for this month |
Newsgroups: comp.compilers
From: parrt@ecn.purdue.edu (Terence J Parr)
Keywords: tools
Organization: Compilers Central
References: 93-06-031 93-06-036
Date: Sat, 12 Jun 1993 19:47:40 GMT

markh@csd4.csd.uwm.edu writes:


> From my experience, I'd say that either (1) you're better off writing it
> by hand because there are less constraints on development -- grammars have
> to be greatly expanded and flexibility squeezed just to fit them into the
> restrictive format required by YACC (which is why my hand written parsers
> tend to be smaller), or (2) finding a better tool that can work directly
> with EBNF grammars, and produce intuitive code in your target language.


PCCTS (Purdue Compiler-Construction Tool Set) has such a "better"
parser generator called ANTLR (ANother Tool for Language Recognition);
I maintain and enhance it. PCCTS is in the public domain and, hence,
can be used with impunity by commercial folks.


> As an illustration, try expressing something like this (which is what I
> work directly off of) efficiently in YACC without a lot of tweaking and
> expansion (it's a segment of a Pascal syntax in an EBNF-like notation) and
> still get intuitive code for it.
>
> Block: "begin" Sequence "end";
> Sequence: ([Statement] ":")* [Statement];
> Statement: LABEL ":" Statement
> | Block
> | Var ":=" Exp
> | NAME ["(" (Param ",")* Param ")"]
> | "goto" LABEL
> | "if" Exp "then" Statement ["else" Statement]
> | "case" Exp "of" ([Case] ";")* [Case] "end"
> | "while" Exp "do" Statement
> | "repeat" Sequence "until" Exp
> | "for" NAME ":=" Exp ("to" | "downto") Exp "do" Statement
> | "with" (Var ",")* Var "do" Statement
> ;
> Case: (Constant ",")* Constant ":" Statement;
> Param: Exp
> | Exp ":" Exp [":" Exp] /* only in i/o */
> ;
> [A better tool would be nice, but yacc's grammar error detection is still
> important. -John]


This is exactly the form of ANTLR input accept that rules must start
with lower case letters (ala YACC) and "[..]" option blocks are
written as "{...}"; actions are in European quotes: <<action>>. We
allow (...)+ blocks (1 or more) also. Note that the strings in
quotes, "...", can be arbitrary regular expressions in ANTLR--we have
merged the description of lexical and syntactic analysis.


ANTLR can provide you the flexibility of hand-written parsers because
it generates recursive descent LL(k) (as opposed to LALR(1)) parsers
written in human-readable C; they can even be debugged with standard
debuggers. Predicates actions, <<predicate>>?, allow semantics to
alter the course of the parse; hence, context-sensitive parsing can be
done just like a hand-written parser. There are way too many features
to describe here.


For more information and how to get PCCTS, send email to
pccts@ecn.purdue.edu with a blank "Subject:" line. The server will
send you a server usage banner. Or, if you prefer, you can converse
with me at parrt@ecn.purdue.edu. Questions about lexical analysis are
more appropriately sent to Will Cohen, the author of our lexical
analyzer generator, at cohenw@ecn.purdue.edu.


Regards,
Terence Parr
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.