Related articles |
---|
Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-02) |
Re: Need starting tips for a new interpreter / parser mslamm@mscc.huji.ac.il (Ehud Lamm) (1999-01-03) |
Re: Need starting tips for a new interpreter / parser anton@mips.complang.tuwien.ac.at (1999-01-03) |
Re: Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-04) |
Re: Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-06) |
Re: Need starting tips for a new interpreter / parser escargo@mirage.skypoint.com (1999-01-06) |
Re: Need starting tips for a new interpreter / parser mslamm@mscc.huji.ac.il (Ehud Lamm) (1999-01-11) |
Re: Need starting tips for a new interpreter / parser Immanuel.Litzroth@pandora.be (Immanuel Litzroth) (1999-01-11) |
[5 later articles] |
From: | Ehud Lamm <mslamm@mscc.huji.ac.il> |
Newsgroups: | comp.compilers |
Date: | 3 Jan 1999 17:59:29 -0500 |
Organization: | The hebrew University of Jerusalem |
References: | 99-01-012 |
Keywords: | interpreter, design, comment |
On 2 Jan 1999, Harald Fjerdingstad wrote:
> I am at the project planning level of making a new parser /
> interpreter for a reporting tool.
It would be easier to answer, if you give more details. Is this tool for
in house use? What types of users (this also relates to error handling)?
What kind of reports (in what ways is your language different from vanilla
pascal)? etc.
> [Sounds like you've skipped the first step, which is to decide whether
> you reallyneed to invent yet another little interpreter. There are
> several high-quality freely available extension languages including
> Python and TCL which are specifically designed to be programming
> frameworks into which one can drop application-specific commands and
> functions.
This is true in some cases and wrong in others. I think that there is a
lot to be said FOR using and creating a proprietry language.
The way I'd go about doing it (and here I am assuming your use is similiar
to the uses I have in mind) is to design a virtual machine layer. I'd
compile (using as regular tools as I can) from the language to VM code,
and interpret the VM. This has several advantages.
* It helps to decompose the work.
* It is usually not so hard to interpret code for a well designed VM.
* If you really want to you can use an avialable VM (this can be
difficult!)
* It helps you design a language you can than impliment in a portable way
acrros platforms.
* You may use the VM layer in places where textual code is not needed (for
exmaple, when you create a GUI tool).
I have more ideas about this topic. if you have more questions ask (either
on comp.compilers or via email).
Ehud Lamm mslamm@pluto.mscc.huji.ac.il
[I agree that if you really need to write an interpreter, compiling to
bytecodes and interpreting those is the way to go. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.