|[Q] Multiple front ends, single back end... firstname.lastname@example.org (Orlando Llanes) (2000-10-31)|
|Re: [Q] Multiple front ends, single back end... email@example.com (Sebastian Moleski) (2000-11-01)|
|Re: [Q] Multiple front ends, single back end... firstname.lastname@example.org (Jean Pariseau) (2000-11-07)|
|From:||"Jean Pariseau" <email@example.com>|
|Date:||7 Nov 2000 13:09:11 -0500|
|Keywords:||lex, yacc, design, comment|
"Orlando Llanes" <firstname.lastname@example.org> wrote in message
> I'm writing a script language and interpreter which will support
> multiple front ends with a single back end. The primary intent is to
> provide a language that can easily be typed and read. The secondary intent
> is to create an interpreter that leaves a small footprint in memory. The
> final intent is speed, both in parsing and execution.
> There are three ways to support multiple front ends; 1) writing
> Lex/Yacc type tools, 2) OO/modular programming interface, and 3) writing
> language translators.
> 1) Lex/Yacc are good in theory, but they have a major learning curve.
> Lex/Yacc tools also produce a lot of code which significantly increases
> the size of the executeable. Also, programming these tools would be
> extremely difficult (for me at least).
As to using Lex/Yacc, stay away.....your parser/lexer would start out
a little easier to develop, but adding anykind of error detection and
recovery would simply be very difficult. If you want to go with
parser generator, you'd be well off to consider something like coco/r
or someother LL(k) or recursive descent parser. Truth be told though,
a recursive descent parser is very easy to construct by hand and you
have total control.
> Are there any other ways I haven't thought of to support multiple
> front ends? What do you think of methods 2 and 3?
Using a base class for a generic front end is a good idea. This would
keep every derived front end consistent with the others. Delphi/C++
Builder are two different front ends that work with a common back end.
For an example of multiple backends, check out the Free Pascal
[I agree that yacc makes it hard to do error recovery, but I find that
yacc parsers usually have better error detection than hand-written ones
because the parser accepts exactly the language in the input grammar and
no more. In hand-written RD parsers it's easy to forget to write some of
the error tests you need to reject invalid tokens at every stage. -John]
Return to the
Search the comp.compilers archives again.