[comp.ai] Lisp Eval in C or C++

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.com

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.

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