(Questions like this should probably go on sbcl-help or sbcl-devel @
lists.sourceforge.net. They're on topic for those lists, so there may
be people on the lists today, or people reading the archives tomorrow,
who want to know about this; and there may be people reading the lists
today who can help. So I'm cc'ing my response to
On Mon, Aug 27, 2001 at 10:07:00PM -0700, John wrote:
> Hi I'm a Lisp newbie and I'm not even sure how to phrase my
> question. I bet I'm going to use some incorrect
> terminology, and maybe what I want to do with SBCL isn't
> even possible so please be gentle:
> What I need to do is integrate the SBCL runtime (I guess
> that's what you'd call it) with a GUI app, not written in
> Lisp. I.e., let's say, in my hypothetical GUI, I have a
> button, and when I click that button I want to submit this
> (defun foo(x) (+ 2 x))
> to SBCL. The effect should be as if the above defun were
> typed by a user at a "listener" window.
> Maybe you can already see where I am going with this: I
> want to expose SBCL as a kind of software component that
> has an interface or set of interfaces. I want to be able to
> use the component in an application that is not necessarily
> written in Lisp.
> As an example: Corman Common Lisp is written as a COM
> server DLL. You can create a Corman Common Lisp "object"
> from your app, which may be written in C/C++/VB, etc. One
> of the functions exposed by the object is "ProcessLispSource
> (char *lispSource)" - you can guess what this does. Now,
> it's not QUITE as simple as calling that function, say:
> CCLObject->ProcessLispSource("(defun foo (x) (+ 2 x))");
> There is more work to do, and I think there are a couple
> more parameters, but you get the idea I hope.
> I suppose this is similar in concept to the way emacs
> works, using Lisp as a language that can be used to extend
> the editor itself. (I'm no emacs expert either :-) ). I
> doubt seriously if emacs is implemented this way, but who
> I hope I have adequately explained what I want to do. I
> have been poking around in the sources but I don't see an
> obvious starting place. If it is even possible, and
> explainable to mere mortals, I'd sure appreciate a nudge in
> the right direction.
> Thanks a lot,
> PS I'm only a newbie at Lisp, I know C/C++ really well.
There are a variety of ways you might be able to go.
Depending on the details of what you're trying to do, you might be
able to write everything in Lisp. If you're a Lisp/SBCL newbie, you
might not realize that you can make C calls from SBCL. The SBCL
FFI/ALIEN/C-CALL documentation is in a state of disarray, but this
part of SBCL is 99% compatible with CMU CL, so for now you can read
the CMU CL documentation (and then translate the package names from
ALIEN to SB-ALIEN and from C-CALL to SB-C-CALL). Also, things like the
SBCL src/code/unix.lisp file, and Dan Barlow's socket library (on
CLiki again) can give you many examples of using this functionality.
One step away from this is writing the non-Lisp part of your program
as a C library, and having SBCL call it. See the documentation string
of SB-ALIEN:LOAD-1-FOREIGN for a trivial example.
You could run SBCL as a subprocess, and have your program talk to it
using something like Perl's IPC::Open2. (I don't know offhand what C
library calls this corresponds to. Use "perldoc IPC::Open2" to ask
your system about it if you don't know Perl.) I do this myself for a
program to play the game of Go, with the think-about-the-game engine
is Common Lisp running on SBCL, and the interface stuff is written in
Perl. This has operations vaguely analogous to your ProcessLispSource,
looking like e.g.
(setf *debugger-hook* #'noprogrammer-debugger-hook)
my ($lisp_output_move) =
(best-move *game* $lisp_who
My experience with this has been mildly positive, since various Perl
support for interface hacking has come in handy. However, there's been
a lot of messy tedium involved, too, and if I were doing it again, I'd
probably write the whole thing in Lisp instead (as above).
You could make SBCL listen(), and have your program connect to it
through a socket. Or you could make your C code listen(), and have
SBCL connect to it. See <http://www.telent.net/cliki/> for pointers to
libraries that will let SBCL do sockets.
You could set up SBCL to use CORBA. However, first you'd probably have
to port CMU CL's CORBA support, since I don't think anyone has done
this with SBCL yet. See CLiki again for pointers on CORBA stuff.
Also, although I think Common Lisp is quite likely to be the best
choice, I should mention that there are a number of other language
implementations which are specifically designed to be used as
extension languages. Thus, the implementation provides support, the
documentation provides examples, and there's a community of other
users doing the same thing with the software. Tcl and Guile (and
several other flavors of Scheme, the names of which escape me) come to
mind. And Perl now has some support for this as well, according to one
of my O'Reilly books somewhere. So if extensive support for use as an
extension language is more important than choice of language, you
might want to look at one of those.
William Harold Newman <william.newman@...>
"Smooth duct tape: the mark of a true craftsman."
-- someone at Bettis Lab, quoted by my father
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C