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. |
hall@aplcen.apl.jhu.edu (Marty Hall) (04/05/91)
In article <1991Apr4.182329.5513@searchtech.com> belinda@searchtech.com (Belinda Hoshstrasser) writes: > [...] Has > anyone out there ever implemented eval in C or C++? Is there public domain > code to do this? Yes, it's called AKCL. :-) :-) - Marty Hall (setf (need-p 'disclaimer) NIL)
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
aboulang@bbn.com (Albert Boulanger) (04/14/91)
In article <4434@skye.ed.ac.uk> richard@aiai.ed.ac.uk (Richard Tobin) 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.
Sadly, the path of going C++ will be taken and by the time all the
infrastructure is there (with a lot of blood and sweat and money)
people will realize that they come out about the same. Take a look at
the Saber C++ environment for example. Not really integrated yet and
just as fat as lisps. Another current trend is towards low road
solutions to problems because of the current "persona" of world-events.
Time flows on in a quasi-periodic way.
I can't wait to see what Moon is up to at Apple.
Albert Boulanger
aboulanger@bbn.combpendlet@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.
bpendlet@bambam.dsd.es.com (Bob Pendleton) (04/18/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. I missed the original posting, working takes so much time out of the day :-) So I'm not sure I'm answering the right question. Yes, I've written eval in C, and PASCAL, and once even in FORTRAN (shudder). It is pretty straight forward. Many years ago I was a TA in a class where we even coached a bunch of undergrads through writing a complete LISP interpreter. I'm currently working (slowly, it's a purely home based for fun project, anybody want to PAY me to do it :-) on a logo interpreter in c++. Creating trees of objects that evaluate themselves looks pretty easy, but I haven't finished it yet. If you have any questions I'd be glad to try to answer them. -- Bob Pendleton, speaking only for myself. bpendlet@dsd.es.com or decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet Tools, not rules. P.S. If all else fails try bpendlet@bambam.dsd.es.com, mail is a little flaky right now.
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