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 am aware of quite a few candidate
lightweight lisp systems :
(a) Gnu Emacs Lisp from FSF
(b) SIOD lisp (and SIOD++) from UIUC
(c) LightLisp from UCB CAD tools
(d) Xlisp and Xscheme from BIX
(e) Mythical Andrew System embedded lisp (rumor only) from CMU
There may be others, I'd like to hear about them.
Does anyone have experience with using these or any other
small lisp systems as embedded macro languages?
For my use the system would need to be written in C or C++,
the source code free or cheap, and with few restrictions on re-distribution.
It would be nice if the code would run on nasty segmented intel
arches under Xenix or MSdos, but only BSD/SUNOS compatability is needed.
I suspect lots of people might be interested in this matter, so post
or mail direct as is your pleasure.
Cheers,
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] ······@rutgers.edu
From: Mike Clarkson
Subject: Re: Looking for an embedded lisp.
Date:
Message-ID: <379@ists.ists.ca>
In article <··························@athos.rutgers.edu>, ······@athos.rutgers.edu (Silver) writes:
> 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!).
MacLisp really.
> If you do it right, things should have a very professional appearance and
> streamlined feel.
It wouldn't be too hard to get emacs trimmed down by leaving a lot of
the C and Lisp files out of the loadup. You could probably make a significant
step towards streamlined performance by doing so.
Mike.
--
Mike Clarkson ····@ists.ists.ca
Institute for Space and Terrestrial Science uunet!attcan!ists!mike
York University, North York, Ontario, FORTRAN - just say no.
CANADA M3J 1P3 +1 (416) 736-5611
From: Mott Given
Subject: Re: Looking for an embedded lisp.
Date:
Message-ID: <1454@dsacg1.UUCP>
From article <·····@pasteur.Berkeley.EDU>, by ····@ernie.Berkeley.EDU (Andy Purshottam):
> Hi, I am about to build a tedious "user-friendly" interface to ...
> (a) Gnu Emacs Lisp from FSF
> (b) SIOD lisp (and SIOD++) from UIUC
> (c) LightLisp from UCB CAD tools
I have never heard of these LISP packages. Can anyone tell me what
the full names and addresses of "FSF", "UIUC", and "UCB" are?
I would also be interested in any comments that anyone has on the
capabilities of these packages.
Mott Given @ Defense Logistics Agency ,DSAC-TMP, Bldg. 27-1, P.O. Box 1605,
Systems Automation Center, Columbus, OH 43216-5002
INTERNET: ······@dsacg1.dla.mil I speak for myself
Phone: 614-238-9431 AUTOVON: 850-9431
--
Mott Given @ Defense Logistics Agency ,DSAC-TMP, Bldg. 27-1, P.O. Box 1605,
Systems Automation Center, Columbus, OH 43216-5002
INTERNET: ··················@daitc.arpa I speak for myself
Phone: 614-238-9431 AUTOVON: 850-9431
> *Excerpts from ext.nn.comp.lang.lisp: 15-Apr-89 Looking for an embedded lisp.*
> *Andy ··········@ernie.Be (979)*
> 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 am aware of quite a few candidate
> lightweight lisp systems :
> (a) Gnu Emacs Lisp from FSF
> (b) SIOD lisp (and SIOD++) from UIUC
> (c) LightLisp from UCB CAD tools
> (d) Xlisp and Xscheme from BIX
> (e) Mythical Andrew System embedded lisp (rumor only) from CMU
> Does anyone have experience with using these or any other
> small lisp systems as embedded macro languages?
> For my use the system would need to be written in C or C++,
> the source code free or cheap, and with few restrictions on re-distribution.
I am the author of the (entirely non-mythical) Andrew System embedded lisp from
CMU (called ELI [Embedded Lisp Interpreter]). It is written in very portable C
and is available on the X11R3 distribution which can be ftp'd from MIT. It
implements an "extended subset" of Common Lisp, and is currently in use as a
filtering language for the Andrew Message System. It is a fairly stable if not
utterly robust package, but when you buy into ELI, you will also be among the
first to know about its upcoming successor, ELSIE (the "Embedded Lisp [Scheme]
Interpreter, 'ELSIE'"), which will be even smaller and faster than ELI and which
will not be an "extended subset" of anything; it will be a proper superset of
the Revised^4 Report on Scheme, complete with a Lisp compatability module and
tons of other wonderful features. If you are interested in discussing ELI or
ELSIE, or indeed any other part of the Andrew system, please check out
comp.soft-sys.andrew. Let me know if I can send anyone any more information.
==============
Bob Glickstein
ITC Database Group
Information Technology Center
Carnegie Mellon University
Pittsburgh, PA
==============
From: Joel Bartlett
Subject: Re: Looking for an embedded lisp.
Date:
Message-ID: <1362@bacchus.dec.com>
Another embeddable LISP you might consider is Scheme->C done at DEC WRL
which is available NOW:
The compiler compiles Revised**3 Scheme to C that is then compiled by
the native C compiler for the target machine. This design results in
a portable system that allows either stand-alone Scheme programs or
programs written in both compiled and interpreted Scheme and other
languages.
Licensing mechanics.
License and software distribution is via paper mail so I will need
your postal address. There is a distribution fee of $100
(U.S.) for the software. Software is distributed on a tar tape in
source form. Like any other research software, it's on an "as is"
basis. If your organization is unwilling to sign the license and you
still want the software, we'll have to discuss it.
Computer systems licensed.
Currently the system runs on top of ULTRIX. It has also been run on
4.2 BSD UNIX. A VMS version has not been made, but it can probably
run under Eunice.
While the software was designed to be portable and has been ported to
three different processors, the terms of the license currently restrict the
software to Digital VAX and DECstation 3100 computers.
Is it really Scheme?
The system supports the essentials (including cwcc) of Revised**3 and many of
the optionals. Extensions include "expansion passing style" macros, a
foreign function call capability, and full support of X11's Xlib. Numbers
are represented internally as 29-bit integers, or 64-bit floating point
values.
The system is oriented towards block compilation to generate code
which can run in standalone programs which may include code from
other languages. While debugging is typically done using the
interpreter, it will never be considered a "Scheme environment".
The one "wart" in the system is that the compiler cannot compile all
tail calls correctly. This follows from some of the design tradeoffs
made when mapping Scheme to C (see tech report).
The compiler is written in Scheme. Most of the runtime system
(including an interpreter) is written in Scheme. The compacting garbage
collector and a few other things are written in C. There is a small
(< 100) amount of assembly code.
Tech report available
A technical report provides details about the design. It includes
some sample code, benchmark data etc. To see the abstract, get a
hard copy, or a Postscript file, send a message with "help" in the subject
line to: ···············@decwrl.dec.com.
If you have specific questions or are interested in license information,
contact me directly.
Joel Bartlett ········@decwrl.dec.com