Interpreters: Summary

nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
Thu, 21 Nov 91 09:55:39 JST

          From comp.compilers

Related articles
Re: Interpreters (and now, byte code standards) nick@nsis.cl.nec.co.jp (1991-11-15)
Interpreters: Summary nick@nsis.cl.nec.co.jp (1991-11-21)
Re: Interpreters: Summary jesup@cbmvax.cbm.commodore.com (1991-11-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
Keywords: interpreter, summary, design
Organization: Compilers Central
References: 91-11-054
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
            being favored.


            POINTS IN FAVOR : Not limited to one language. Fast. Easily
                                                extended.
            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.


RESOURCES AVAILABLE
===================


TCL
    References : Paper in USENIX 89.
    FTP : sprite.berkeley.edu


BYTECODE
    References :
    FTP ~ftp/pub/src/fools/tar.Z (fools lisp)
                              XScheme


TREE BASED
    References :
    FTP : GNU Awk




BOOKS
    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,
Japan
Phone : <Japan> (044) 812-8411
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.