gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Various questions about GCL


From: jeff
Subject: Re: [Gcl-devel] Various questions about GCL
Date: Wed, 29 Sep 2004 16:17:23 +0100
User-agent: Internet Messaging Program (IMP) 3.2.3

Quoting Camm Maguire <address@hidden>:

> "Goffioul Michael" <address@hidden> writes:

> > 1) Would it be possible to make GCL embedded into a C library
> > (preferably shared) such that a 3rd party application could make
> > use of GCL as an embedded computation engine? This would mean to
> > have an API to initialize/terminate the GCL engine, to convert
> > between C types and LISP objects, to "eval()" or "funcall()"
> > arbitrary code. Our final target is actually to embed a LISP engine
> > into a MEX file such that our framework written in LISP can be
> > accessed from the MATLAB user interface.

There at least used to be a Common Lisp, Wade's Common Lisp (WCL),
that was packaged as a shared library.  I think that it still
exists and that there is a version for Linux.  See

http://www.bie.no/products/phpodp/odp.php?browse=/Computers/Programming/Languages/Lisp/Compilers_and_Interpreters/

and, more directly, http://wcl.kontiki.com/ where it says:

  The goal of WCL is to allow hundreds of Lisp applications to
  be realistically available at once, while allowing many of them
  to run concurrently.

ECo Lisp (ECL), which I think was derived in part from KCL,
is meant to be embedded.  See the link on the page at
the other end of the long URL above.

CLiCC (The Common Lisp to C Compiler) may also be relevant.
See: http://www.informatik.uni-kiel.de/~wg/clicc.html

> This is one of the topics I would like to discuss in setting
> directions for GCL 2.7.x development.  In my opinion, lisp as
> conventionally used is naturally limited to applications of great
> complexity in a mostly single user environment.

That doesn't sound right to me.  I often use Common Lisp for
simple applications, and Common Lisp has often been used on
time-sharing machines with multiple simultaneous users.

There is, as you pointed out, an issue when running many
simultaneous copies, because the application code will be
dynamically loaded and hence not be shared.

However, so-called scripting languages have the same sort of
problem, and that doesn't stop people from thinking they are
usable in many-user situations.

For Lisp, one good solution would be to provide a way for
application code to be turned into a shared library or otherwise
be linked in as text rather than be dynamically loaded
into the heap.

(In some cases, even creating an application using dynamic loading
followed by a save-system should work failrly well given copy on write.)

-- Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]