|A JavaCC book firstname.lastname@example.org (Tom Copeland) (2007-07-19)|
|Re: A JavaCC book email@example.com (Eric) (2007-07-23)|
|Re: A JavaCC book firstname.lastname@example.org (Tom Copeland) (2007-07-26)|
|From:||Tom Copeland <email@example.com>|
|Date:||Thu, 26 Jul 2007 09:27:56 -0400|
|Keywords:||Java, parse, books|
On Mon, 2007-07-23 at 15:12 -0700, Eric wrote:
> On Jul 19, 9:34 am, Tom Copeland <t...@infoether.com> wrote:
> > Folks working with Java may be familiar with the LL(k) parser
> > generator JavaCC. This fine utility has been around almost as long as
> > Java has, but the documentation has always been slightly lacking.
> > Thus my new book: "Generating Parsers With JavaCC".
> > http://generatingparserswithjavacc.com/
> Looks great! The source code examples haven't been posted yet but the
> TOC looks good.
Yup, just posted them, albeit all in one zip file:
> I noted the cool chapter on testing the various parts
> of a compiler with Junit. Automated testing is more than a current
> fad, especially in the compiler business! Many hours can be saved this
> way and the savings are almost guranteed to dwarf the extra time
> needed to set it up.
Right on, I hope so; and JUnit 4 makes writing tests a bit less tedious
than before, too. I'm rather fond of the "use XPath to test an AST"
thing also, it's quite handy!
> Unlike many compiler books you seemingly didn't make a "toy language"
> compiler that progresses with each chapter. We've come to expect that,
> but it has a down-side of alienating people who aren't happy with the
> toy language, and it also uses a lot of pages that might be better
> used to introduce more topics. Your website has some toy language
> stuff (Jave to Python, and the HTMLizer), so that probably meets the
> toy language requirement.
> I will look into this book further!
> Considering your Ruby credentials, would I be far off track to guess
> there may be a Ruby example forthcoming?
Hehe, yup, I've been looking into writing an ERB parser and checker -
something that would report suboptimal constructs like <%= "foo" %>
(e.g., there's no need to use an ERB code sequence for a literal
string). We'll see! That Ruby parse.y file is pretty hairy....
Return to the
Search the comp.compilers archives again.