From: | Gene <gene.ressler@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Mon, 17 Nov 2008 17:28:31 -0800 (PST) |
Organization: | Compilers Central |
References: | 08-11-061 |
Keywords: | lex, parse, practice |
Posted-Date: | 18 Nov 2008 19:09:54 EST |
On Nov 15, 12:49 pm, "tuxisthebirdfo...@gmail.com"
<tuxisthebirdfo...@gmail.com> wrote:
> I know most people anymore use lex/yacc or some derivative of these
> tools to create scanner/parser modules for their compiler projects. I
> was wondering if anyone has developed a scanner or parser that they
> personally hand-wrote? If so, I would like to know what language you
> used and what type of grammar you parsed. If you feel divulgent,
> please tell me a little bit about you're implementation or what you
> did for intermediate representation. I'm curious and just a bit nosy
> and would like to know how you're experience went doing things this
> way. Thanks.
> [I hand-wrote a scanner for Fortran 77 about 30 years ago. It worked but
> it was pretty gross because Fortran's lexical structure is so strange.
-John]
I've done both. My sense is that if you need a quick tool where the
input language is likely to change and error recovery is not a big
deal, the lex/yacc approach works well.
On the other hand if you are working on a stable syntax or where
detailed error reporting is needed, you're better off rolling your
own.
Your claim that lex/yacc (or other similar tools) are used by most
people is probably too general. Last time I looked, the C and c++
front ends of gcc used a hand-written lexer with bison parser, and the
preprocessor (which includes a lexer) was entirely hand-written. I've
read that the gcc team has in the past regretted bison because error
messages have been hard to get right. The Ada front end of gcc is
entirely hand-written, recursive descent. Perl uses yacc (at least
through v5) but with a hand-written tokenizer. Python seems to
generate its own parser from a grammar during startup. Yada yada. At
least for production compilers, it's more of a mixed bag than you
infer.
Good luck!
Return to the
comp.compilers page.
Search the
comp.compilers archives again.