belinda@searchtech.com (Belinda Hoshstrasser) (04/05/91)
We are involved in redoing a large expert system in C++. It was originally written in Lisp. Much of our reasoning is based on constraint evaluation, which is very easy in Lisp. However, it is not very easy or elegant in a more structured language like C or C++. Basically, what we need is something that can evaluate constraints -- something similar to eval in Lisp. Has anyone out there ever implemented eval in C or C++? Is there public domain code to do this? If not, we would appreciate any advice or experiences from anyone who has had face a similar problem. Thanks!!! -- ------------------------------------------------- | Belinda Hoshstrasser | | belinda@searchtech.com | | Search Technology, Inc. |
torek@elf.ee.lbl.gov (Chris Torek) (04/05/91)
In article <1991Apr4.182329.5513@searchtech.com> belinda@searchtech.com (Belinda Hoshstrasser) writes: >We are involved in redoing a large expert system in C++. It was >originally written in Lisp. ... Has anyone out there ever implemented >eval in C or C++? What this all boils down to is: We have a program in Lisp. We want to reimplement it in C++ syntax with Lisp semantics. If you want Lisp semantics, you might as well use Lisp syntax: you already have the original anyway. There exist good Lisp compilers for many Lisp dialects, so the argument for converting the program should not hinge on compiled-vs-interpreted. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
richard@aiai.ed.ac.uk (Richard Tobin) (04/05/91)
In article <11809@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >>We are involved in redoing a large expert system in C++. It was >>originally written in Lisp. ... Has anyone out there ever implemented >>eval in C or C++? >What this all boils down to is: > We have a program in Lisp. We want to reimplement it in > C++ syntax with Lisp semantics. >If you want Lisp semantics, you might as well use Lisp syntax I agree. There seems to be a rush to convert Lisp systems to C (or C++) just at the time when the standard complaints about the size and speed of Lisp implementations are becoming irrelevant. Memory really *is* cheap - I just bought 16Mb for my home machine for less than 600 pounds - and processor speeds are increasing so that if you need to double your speed the easiest thing to do is wait a year rather than rewrite in C. Add to this the advantages of built-in garbage collection and extension language, and Lisp becomes the obvious choice. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
bliss@sp64.csrd.uiuc.edu (Brian Bliss) (04/06/91)
In article <1991Apr4.182329.5513@searchtech.com> belinda@searchtech.com (Belinda Hoshstrasser) writes: >We are involved in redoing a large expert system in C++. It was >originally written in Lisp. ... Has anyone out there ever implemented >eval in C or C++? I'm working on an implementation of it. I basically boils down to writing a C interpreter. The project is called the applicaton executive, and the syntax off the call is: int sae (register char *string, char *retloc, char *routine, ... ) string - the text to be evaluated retloc - pointer to where we store the return value, if we are interpreting an entire function routine - the name of the routine to interpret, followed by it's arguments return value is number of errors. so if we have int val; sae ("int func (int x, int y) { return (x + y); }", &val, "func", 3, 4); then the value of val is set to 7. bb
libes@cme.nist.gov (Don Libes) (04/09/91)
In article <1991Apr4.182329.5513@searchtech.com> belinda@searchtech.com (Belinda Hoshstrasser) writes: >Basically, what we need is something >that can evaluate constraints -- something similar to eval in Lisp. Has >anyone out there ever implemented eval in C or C++? Is there public domain >code to do this? If not, we would appreciate any advice or experiences from >anyone who has had face a similar problem. We've used Tcl in a number of projects as a quick way of getting dynamic expression evaluation in C programs. It's public-domain, portable to SV and BSD, well-documented, and easy to use and extend. In only 45k, it doesn't do everything (scoping and data structures are fairly unsophisticated) but since I began using it, I've dramatically cut down on my yacc/lex usage. Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes
gowj@novavax.UUCP (James Gow) (04/10/91)
In article <1991Apr5.234351.22542@csrd.uiuc.edu> bliss@sp64.csrd.uiuc.edu (Brian Bliss) writes: >In article <1991Apr4.182329.5513@searchtech.com> belinda@searchtech.com >(Belinda Hoshstrasser) writes: >>We are involved in redoing a large expert system in C++. It was >>originally written in Lisp. ... Has anyone out there ever implemented >>eval in C or C++? > How bout David Betz? He wrote a c interpreter for xlisp. He may be available on Compuserve since newer versions of xlisp are said to be available there. linc James
bpendlet@bambam.dsd.es.com (Bob Pendleton) (04/18/91)
In article <4434@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes: > In article <11809@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: > >If you want Lisp semantics, you might as well use Lisp syntax > > I agree. There seems to be a rush to convert Lisp systems to C (or > C++) just at the time when the standard complaints about the size and > speed of Lisp implementations are becoming irrelevant. Memory really > *is* cheap - I just bought 16Mb for my home machine for less than 600 > pounds - and processor speeds are increasing so that if you need to > double your speed the easiest thing to do is wait a year rather than > rewrite in C. Add to this the advantages of built-in garbage > collection and extension language, and Lisp becomes the obvious > choice. You are, of course, correct. But. In a commercial environment your sales will be higher if you run on the computer the cutomer already owns. Cutting your memory usage in half can more than double your sales. And you won't sell anything today if you need next years processor to make it run acceptably fast. The origninal poster said "large." The company I work for sells a "large" LISP application. Even compiled it can bog down a 128 meg R3000. Not mention that having the application "go to lunch" for 5 minutes at random times while it is garbage collecting is a serious user interface problem. Customers Will Not Accept It. So... as much as I like LISP I don't think it is a good language for writing commercial applications. -- Bob Pendleton, speaking only for myself. bpendlet@dsd.es.com or decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet Tools, not rules.
gwyn@smoke.brl.mil (Doug Gwyn) (04/18/91)
In article <1991Apr17.170547.19511@dsd.es.com> bpendlet@dsd.es.com writes:
-In a commercial environment your sales will be higher if you run on
-the computer the cutomer already owns. Cutting your memory usage in
-half can more than double your sales. And you won't sell anything
-today if you need next years processor to make it run acceptably fast.
-The origninal poster said "large." The company I work for sells a
-"large" LISP application. Even compiled it can bog down a 128 meg
-R3000. Not mention that having the application "go to lunch" for 5
-minutes at random times while it is garbage collecting is a serious
-user interface problem. Customers Will Not Accept It.
-So... as much as I like LISP I don't think it is a good language for
-writing commercial applications.
While this isn't much relevant to C as such, this is the newsgroup
I saw the above in, and I feel obliged to point out that Lisp
implementations need not be large, nor slow, nor perform garbage
collection in a disruptive way. Incremental garbage collection
techniques have been published for many years now (I think I saw
one in CACM not long before it turned into a yuppie magazine).
There are even special hardware architectures (Lisp machines) for
people who are heavily into Lisp-based applications.davis@barbes.ilog.fr (Harley Davis) (04/20/91)
In article <1991Apr17.170547.19511@dsd.es.com> bpendlet@bambam.dsd.es.com (Bob Pendleton) writes: > I agree. There seems to be a rush to convert Lisp systems to C (or > C++) just at the time when the standard complaints about the size and > speed of Lisp implementations are becoming irrelevant. Memory really > *is* cheap - I just bought 16Mb for my home machine for less than 600 > pounds - and processor speeds are increasing so that if you need to > double your speed the easiest thing to do is wait a year rather than > rewrite in C. Add to this the advantages of built-in garbage > collection and extension language, and Lisp becomes the obvious > choice. You are, of course, correct. But. The origninal poster said "large." The company I work for sells a "large" LISP application. Even compiled it can bog down a 128 meg R3000. Not mention that having the application "go to lunch" for 5 minutes at random times while it is garbage collecting is a serious user interface problem. Customers Will Not Accept It. So... as much as I like LISP I don't think it is a good language for writing commercial applications. Speak for your own Lisp. _My_ company sells a Lisp (Le-Lisp) and Lisp-based applications which rarely exceed 4 megabytes (and even that is considered large). Customers almost never complain about process size or speed. This, added to the convenience and power of Lisp programming compared to C, has allowed us to become Europe's biggest Lisp and AI tool vendor. I don't think most users of Scheme or the various Lispy extension languages complain about their memory use either. In general, people should be careful when saying "Lisp". There is no one dialect which deserves the title "Lisp". If you are thinking of Common Lisp, or some specific vendor's Common Lisp, say so. Not all Lisps are large or slow. -- Harley Davis -- ------------------------------------------------------------------------------ nom: Harley Davis ILOG S.A. net: davis@ilog.fr 2 Avenue Gallie'ni, BP 85 tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France