Using a parser generator in next generation VCL compiler

[Poul-Henning Kamp]

In message <458BD522.3090304 at linpro.no>, =?ISO-8859-1?Q?Knut_Aksel_R=F8ysland?=
 writes:

>I have spent most time looking at the internals of the VCL-compiler.
>[...]

>Any thoughts?

I deliberately didn't use lex/yacc in v1 because the VCL language
is so simple but mostly because I wanted strong error handling.

YACC generated grammers and LEX generated lexers have horrible
error detection and reporting.

If you try to make up for that deficiency, your .y and .l files
become unreadable as a result, more than negating any advantage
of having used them in the first place.

Remember that the people who are going to write VCL programs are
not programmers, they are admins, they may know a bit of perl
or php, but they are not programmers.

We need to give them really good error messages, or they will
hate VCL with a venegance.

But since most of what we will be adding to VCL is the
actions, it might very well be a good idea to spend some
time on unifying their argument handling, and possibly,
use a table driven matching of them, rather than the
current swich {} in Action(), lest it become too horrible.

I know this runs counter to conventional thinking in compiler
circuits, but I'm not alone in thinking that lex/yacc is over-
and under-kill for simple languages.  See for instance the LCC
book which provided a lot of my inspiration for the VCL compiler.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.