|[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:||Orlando Llanes <email@example.com>|
|Date:||31 Oct 2000 14:44:34 -0500|
|Keywords:||UNCOL, design, comment|
|Posted-Date:||31 Oct 2000 14:44:34 EST|
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
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).
2) OO/modular programming would define a base class that works on
anything that can be generalized. A scanner/parser/"compiler" would be in
one class, a symbol table in another (which would be used by the
compiler), and then a seperate class would function as the virtual
machine. The base scanner's behavior could be modified through a small
table (256 element array of character codes) and switches (4 to 6 Boolean
variables, or a "bit mapped" integer) rather than overriding code since
returning EOLN, strings, numbers, and identifiers are fairly consistant
across languages. With the exception of required functions for the VM and
maybe math expressions, parsing would be left up to the programmer. The
compiler would serve as a back end with functions to produce the VM
"executeable" (opcodes, data, etc).
3) Writing a language translator means parsing another language and
converting it into the "native" language.
Are there any other ways I haven't thought of to support multiple
front ends? What do you think of methods 2 and 3?
[I don't know of any easy way to write compiler front ends for nontrivial
Return to the
Search the comp.compilers archives again.