Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!athos.rutgers.edu!gaynor
From: gaynor@athos.rutgers.edu (Silver)
Newsgroups: comp.lang.lisp
Subject: Re: Looking for an embedded lisp.
Message-ID: <Apr.15.09.17.47.1989.23420@athos.rutgers.edu>
Date: 15 Apr 89 13:17:48 GMT
References: <12458@pasteur.Berkeley.EDU>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 58

andy@ernie.berkeley.edu writes:
> Hi, I am about to build a tedious "user-friendly" interface to some stupid
> university software, and need to select a lisp for use as a macro-language in
> the system.

I've used GNU Emacs as an interface for other programs (many such interfaces
can be found in the provided libraries), and highly recommend it.  The lisp
itself is based upon a subset of Common Lisp (no shouts of joy from me!).

Pros:

  1. It provides a kickin' interface.  Your interface program, written in GNU
     Emacs Lisp, has total control over the display and the input to its
     inferior processes.
  2. Process management is fairly easy.
  3. Process communication is fairly easy.
  4. Very advanced string matching/manipulation facilities.
  5. GNU Emacs is very portable shareware.
  6. Wide audience of friendly, helpful experts (see comp.emacs and gnu.emacs).
  7. Diverse and extensive libraries.
  8. Noteworthy on-line help facilities.

Cons:

  1. No floats in GNU Emacs Lisp.  For your purposes (and most editing
     purposes, it seems) this probably isn't a killer.
  2. No direct terminal control by subprocesses.  This is the alter ego of Pro
     #1 above.  For your purposes, this probably isn't a killer, as I'm
     guessing your "stupid university software" doesn't try to do anything
     fancy with the screen.
  3. No native-code compiler.  Emacs has a compiler which produces pcode, and
     the pcode interpreter moves ok, though.
  4. GNU Emacs is resource hungry.

Modus operandi:

  Usually things are event-driven.

  A sentinel function may be associated with a process to `guard' it's state.
  When the process changes state, the sentinel function is called.  It is
  passed the process and a description of the change.

  A filter function may be associated with a process to process it's output.
  When the process generates output, the filter function is called.  It is
  passed the process and the output string.  (Parsing output at this level
  sometimes gets hairy.)

  Process output can also be sent to a buffer, and processed there en masse.

  You provide a bunch of commands that send strings to the process on its
  standard input stream, or somehow affect the process's state.

If you do it right, things should have a very professional appearance and
streamlined feel.

Comments welcome.

Regards, [Ag] gaynor@rutgers.edu