I recently inherited an unexpected project that requires a scripting
language embedded into an application that's already written in C++.
The decision has been made to use Lua (www.lua.org) because
a. Lua has lots of incorporation options. It can be incorporated into
a project with its source code, linked against as a static library, or
bound as a dynamic library.
b. Lua has a two way bridge. So C++ code can call into Lua, and Lua
can call functions in it's C++ host.
c. Lua is cross platform. This needs to run on Mac OS X and Windows.
And maybe someday Linux, but that's not required.
d. Lua is ANSI C, and with the exception of the C standard libraries,
is not dependent upon other outside systems.
But while Lua is great as a lightweight language, the whole thing
irked me because I had been looking forward to a different project
that would be written in Lisp, and now, instead, I am again back in C
land and lispless.
So, I googled about and came up with several embedded options for
embedding Lisp into another application, and since it took me awhile
to gather up this information, I thought I might summarize it here, so
at least someone googling in the future will find this August 2003
c.l.l thread. It's not complete, but perhaps others can reply in the
gaps, especially in regard to Linux/Unix which I often passed over.
Common Lisps:
I couldn't find a Common Lisp which could be incorporated as source
code or linked against as a static library. But some allow the
building of shared/dynamic libraries. The Common Lisps that can build
a dynamic library can always export functions so C can call Lisp. But
the reverse is often limited to importing callable functions from a
DLL. But that's a problem if you are writing a host _application_
which doesn't export functions(*). So Lisp implementations that limit
their ability to call C to imported functions are more difficult to
use embedded.
LispWorks (www.lispworks.com): LispWorks can build DLL's on
Windows, but, unfortunately, cannot build shared libraries under OS X.
However LispWorks does have a nice FLI macro
FLI:DEFINE-FOREIGN-FUNCALLABLE which will let you bind a C pointer,
thus completing a nice two-way C-Lisp bridge.
Allegro (www.franz.com): Allegro Common Lisp can build DLL's on
Windows and shared libraries on OS X. I don't know if it can bind to a
C function ptr.
Corman (www.cormanlisp.com): Corman Common Lisp is Windows only. It
can build DLLs. Calling a C pointer is not documented in the
documentation, but, supposedly, is do-able. It has an assembler built
in, for Pete's sake, so I don't doubt it could be done.
MCL (www.digitool.com): Digitool's MCL is Mac only. According to a
representative at Digitool it can build shared libraries and the
Lisp-C bridge is do-able but would "require some work". Unfortunately
their ftp site has been down so I wasn't able to test this firsthand
nor peruse the documentation.
Anyone want to fill in gaps on the Unix Lisps (SBCL, CLISP, CMUCL, et
al)?
ISLisp:
There are two ISLisp (www.islisp.info) implementations that can be
incorporated at the source code level. Both are interpreters.
OpenLisp (www.eligis.com): I didn't get to use this first hand, but
this looks very complete. It's available on many platforms, has
robust libraries, a full C-Lisp bridge. It also has a small library of
Common Lisp compatability routines to make it more like Common Lisp.
It runs interpreted, but has an exporter to generate C code, if
needed. Commercial and expensive.
TISL (www.ito.ecei.tohoku.ac.jp/TISL/index_j.html): TISL was a student
project released to the public. It has a nice C-to-Lisp bridge, but
the documentation is in Japanese. I was able to get this to work
easily, but couldn't figure out if there was a Lisp-to-C bridge as
well. I presume there is. It's ANSI C and I got it to work on OS X
and Windows.
Scheme and Other Lisps
All run interpreted.
JLisp (www.tcp4me.com/code:) Jeff Weisberg's Lisp - available as
source code, license status unclear. I'm not sure how complete of a
"Common Lisp" implementation this is, but seems to depend upon GNU - I
couldn't get it to compile embedded. Probably just needs some more
elbow grease.
XLisp (www.mv.com/ipusers/xlisper): XLisp 3.0 from David Betz -
available as source code. This is permission ware and ANSI C. It has
a nice two way Lisp-C bridge. This is more Scheme than Lisp. Works
like a champ.
Librep (librep.sourceforge.net): Unix. Intended for embedding. I have
no more info.
Guile (www.gnu.org/software/guile/guile.html): GNU. Can be used with
<a href="http://www.swig.org">SWIG</a> to bridge. Available on many
platforms.
MzScheme (www.plt-scheme.org/software/mzscheme): Available as a COM
control under Windows, but I don't know if it's usable as a shared
library on OS X or Linux. I do not have any information about
calling/being called by C.
Hedgehog? I googled up tidbits but nothing substantial.
Ultimately I ended up incorporating XLisp with David Betz's
permission. So now we have a choice: Lua or xLisp. Let the best
language win.....
Chris Perkins
Media Lab, Inc.
(*)I seem to recall that Windows applications _can_ export functions,
but I don't think Mac ones can. Either way, I'm not sure if one could
call "LoadLibrary" on a running app.
········@medialab.com (Chris Perkins) writes:
> So, I googled about and came up with several embedded options for
> embedding Lisp into another application, and since it took me awhile
> to gather up this information, I thought I might summarize it here, so
> at least someone googling in the future will find this August 2003
> c.l.l thread. It's not complete, but perhaps others can reply in the
> gaps, especially in regard to Linux/Unix which I often passed over.
>
>
> Common Lisps:
>
> I couldn't find a Common Lisp which could be incorporated as source
> code or linked against as a static library. But some allow the
> building of shared/dynamic libraries. The Common Lisps that can build
> a dynamic library can always export functions so C can call Lisp. But
> the reverse is often limited to importing callable functions from a
> DLL. But that's a problem if you are writing a host _application_
> which doesn't export functions(*). So Lisp implementations that limit
> their ability to call C to imported functions are more difficult to
> use embedded.
This is exactly what ECL (Embeddable Common Lisp) is for:
http://ecls.sf.net/
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> This is exactly what ECL (Embeddable Common Lisp) is for:
> http://ecls.sf.net/
>
Yes, you're the second person to tell me. When I google for "embed
Common Lisp", the first mention of ECL is seven pages back from a
Lemonodor posting.
Erik Winkels, who is using ECL in Quake2, reports that the FFI isn't
quite there, and porting it may take some work. But from what I see
on the website it looks impressive. I'm downloading it and hope to
give it a whirl this weekend.
Chris
From: Erik Winkels
Subject: Re: Lisp embedded scripting language report
Date:
Message-ID: <87ispbyxt8.fsf@xs4all.nl>
········@medialab.com (Chris Perkins) wrote:
>
> Erik Winkels, who is using ECL in Quake2, reports that the FFI isn't
> quite there,
Not that I've offered any of my time to the project to work on it, due
to both a lack of skill and a lack of time. I've barely spent half a
day with ECL and Q2 in four weeks.
Still, everyone who is interested in embedding CL in other
applications should check ECL out. It is coming along quite nicely.
http://ecls.sourceforge.net/
Erik
In article <····························@posting.google.com>,
········@medialab.com (Chris Perkins) wrote:
> So, I googled about and came up with several embedded options for
> embedding Lisp into another application, and since it took me awhile
> to gather up this information, I thought I might summarize it here, so
> at least someone googling in the future will find this August 2003
> c.l.l thread.
I'd suggest that this could be an excellent starting point for a page on http://alu.cliki.net
Pascal
On 5 Aug 2003 11:26:18 -0700, Chris Perkins <········@medialab.com> wrote:
>I recently inherited an unexpected project that requires a scripting
>language embedded into an application that's already written in C++.
>The decision has been made to use Lua (www.lua.org) because
>
[snip]
>
>XLisp (www.mv.com/ipusers/xlisper): XLisp 3.0 from David Betz -
>available as source code. This is permission ware and ANSI C. It has
>a nice two way Lisp-C bridge. This is more Scheme than Lisp. Works
>like a champ.
>
you may also have a look at xlisp-plus 2.1 f, a descendant of the
original xlisp. It is more common lisp like than xlisp3.0. Also there
is Xlispstat, another descendant of xlisp. It has a C function wrapper
interface, foreign pointers, can be embedded (RXlisp), and a graphics
library with a lot of statistical functions, byte code interpreter only.
marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
On 6 Aug 2003 09:12:33 +0100, ······@No-Such-Domain.anywhere (see.signature) wrote:
> On 5 Aug 2003 11:26:18 -0700, Chris Perkins <········@medialab.com> wrote:
> >I recently inherited an unexpected project that requires a
> >scripting language embedded into an application that's already
> >written in C++. The decision has been made to use Lua
> >(www.lua.org) because
>
> you may also have a look at xlisp-plus 2.1 f, a descendant of the
> original xlisp. It is more common lisp like than xlisp3.0.
But, from <http://www.almy.us/xlisp.html>:
"XLISP-PLUS contains the work of many individuals. While most have
contributed their efforts to the public domain, a few reserve their
copyrights when Xlisp is used commercially. For that reason,
XLISP-PLUS is only distributed for non-commercial (or educational)
use. Don't ask me about commercial applications."
I think the OP was talking about a commercial project.
Edi.
On 06 Aug 2003 09:56:18 +0200, Edi Weitz <···@agharta.de> wrote:
>
>But, from <http://www.almy.us/xlisp.html>:
>
> "XLISP-PLUS contains the work of many individuals. While most have
> contributed their efforts to the public domain, a few reserve their
> copyrights when Xlisp is used commercially. For that reason,
> XLISP-PLUS is only distributed for non-commercial (or educational)
> use. Don't ask me about commercial applications."
>
>I think the OP was talking about a commercial project.
>
>Edi.
yes, thats true. But the copyright for Xlispstat is different. It
allows commercial use.
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
········@medialab.com (Chris Perkins) writes:
<mondo snippage>
> Anyone want to fill in gaps on the Unix Lisps (SBCL, CLISP, CMUCL,
> et al)?
I am not really sure if ThinLisp is Unix-only, but I don't think so.
It seems to be somewhat relevant to what you are asking, though.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_