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) |
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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.