|Re: Interpreters (and now, byte code standards) firstname.lastname@example.org (1991-11-15)|
|Interpreters: Summary email@example.com (1991-11-21)|
|Re: Interpreters: Summary firstname.lastname@example.org (1991-11-23)|
|From:||email@example.com (Gavin Thomas Nicol)|
|Keywords:||interpreter, summary, design|
|Date:||Thu, 21 Nov 91 09:55:39 JST|
The following is a summary of email responses to the recent question
about the best way to implement an Application Extension Language Interpreter.
First though I would like to extend my thanks to everyone who responded!!
The comments proved very useful!!
I will not post the names of those who reponded to the net as some people
may not wish it. If anyone wants a complete summary (about 20 responses)
please email. I will send a copy to you ASAP.
1) YOU SHOULD USE TCL.
About 6 people responded with this, or suggested looking at it at
least. Some people also suggested Python or Scheme.
POINTS IN FAVOR : Standard. Don't have to roll your own.
POINTS AGAINST : Slow. Difficult syntax.
2) USE A BYTECODE INTERPRETER
These people were the first to respond. Around 8 people suggested
using virtual machines of various sorts, with RISC style machines
POINTS IN FAVOR : Not limited to one language. Fast. Easily
POINTS AGAINST : Basically need a compiler. Deciding the machine
strcuture is difficult. Rebuilding source is tough.
3) USE THREADED SUBROUTINES.
This contigent responded last. I musta admit that this idea was
relatively new to me. I had heard of it, but never considered it.
POINTS IN FAVOR : Easy to implement, just write subroutines. FAST.
POINTS AGAINST : Can be difficult to maintain. Lots of pointers.
4) INTERPRETED PARSE TREES.
This was a minority group.
POINTS IN FAVOR : Easy to implement. Good link to source.
POINTS AGAINST : Slow. Lots of pointer thrashing.
References : Paper in USENIX 89.
FTP : sprite.berkeley.edu
FTP ~ftp/pub/src/fools/tar.Z (fools lisp)
FTP : GNU Awk
Author : Mak, Ronald,
Title : Writing Compilers and Interpreters:
An Applied Approach
Publisher : John Wiley & Sons, 1991. ISBN#0-471-55580-0
(Includes a disk)
Provides compiler/interpreter for pascal.
Again, thanks a lot to all who reponded. I started by being heavily in
favor of BYTECODE, and I guess I still am, as the user would not be tied
to one language. However, before I decide completely, I'll look at the
others too. (Sorry, TCL is out I do *NOT* like the syntax.)
Gavin Nicol (alias "nick" or "nick-san")
NEC Scientific Information System Development Ltd.
R&D KSP Bldg.
100-1 Sakato Takatsu-ku, Kawasaki, Kanagawa-ken 213,
Phone : <Japan> (044) 812-8411
Return to the
Search the comp.compilers archives again.