andy@ernie.Berkeley.EDU (Andy Purshottam) (04/15/89)
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
gaynor@athos.rutgers.edu (Silver) (04/15/89)
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
ntm1169@dsacg1.UUCP (Mott Given) (04/17/89)
From article <12458@pasteur.Berkeley.EDU>, by andy@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: mgiven@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: mgiven%dsacg1.uucp@daitc.arpa I speak for myself Phone: 614-238-9431 AUTOVON: 850-9431
bobg+@andrew.cmu.edu (Robert Steven Glickstein) (04/17/89)
> *Excerpts from ext.nn.comp.lang.lisp: 15-Apr-89 Looking for an embedded lisp.* > *Andy Purshottam@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 ==============
mike@ists.ists.ca (Mike Clarkson) (04/18/89)
In article <Apr.15.09.17.47.1989.23420@athos.rutgers.edu>, gaynor@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 mike@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
bartlett@decwrl.dec.com (Joel Bartlett) (04/25/89)
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: wrl-techreports@decwrl.dec.com. If you have specific questions or are interested in license information, contact me directly. Joel Bartlett bartlett@decwrl.dec.com