Hi All,
First off: I am /rather/ new to Lisp and considering to do something
usefull with it.
I want to write a application which will be somewhat complex. I've
thought about it and want to distribute the application in the form of
plugins, where each user can potentially only download the plugins
he/she will require. Similar to how winamp does it on win32.
My question: How will a plugin type thing work on lisp? is this a
implimentation dependant issue? (ie Clisp vs Franz vs whatever else)
In c++ I would make a nice base class with a bunch of pure virtuals.
The .so or .dll will return a pointer to an instance of the base class
and so the story goes. Is the approach in Lisp similar?
Regards
Pieter
PS - I've read about the whole "compile to native code" and binaries
bla bla issue. The answer to that is not what I am looking for. :)
·······@lynxgeo.com (Pieter) writes:
> My question: How will a plugin type thing work on lisp?
A nice way to do do plugins with lisp is to do it the lisp way: Let
the plugins be "fasl" files (files produced with compile-file), and
simply use LOAD to load them. I don't do this myself, but I do
something very similar - I distribute patches as fasl files.
--
(espen)
·······@lynxgeo.com (Pieter) writes:
> My question: How will a plugin type thing work on lisp? is this a
> implimentation dependant issue? (ie Clisp vs Franz vs whatever else)
Adding stuff to a running system is not something particularly hard in
Lisp; after all, people do it all the time during development. It
should be mostly trivial to create something that works and is
portable.
> In c++ I would make a nice base class with a bunch of pure virtuals.
> The .so or .dll will return a pointer to an instance of the base class
> and so the story goes. Is the approach in Lisp similar?
There is not much need for abstract base classes in Lisp, given
generic functions. Just define the protocol a plugin has to follow
(however you choose to do it, in the extreme case just as
non-executable documentation, although defgenerics and perhaps some
default methods may be useful). Then have each implementation provide
specialized methods on a class it defines. To get an instance of such
a plugin-provided class, you could for example have methods
specialized on the name of the plugin as a symbol, like in
(defgeneric get-plugin-defined-thing (plugin-name))
; in plugin 1
(defmethod get-plugin-defined-thing ((plugin-name (eql :plugin-1)))
(make-instance 'plugin-1:thing))
; in plugin 2
(defmethod get-plugin-defined-thing ((plugin-name (eql :plugin-2)))
(make-instance 'plugin-2:thing))
To load the plugins, either use plain LOAD with a naming convention
that allows you to find the thing to load (for example such that
"plugin-1" can be loaded with `(load "yourapp:plugins;plugin-1")'), or
use a system definition library like ASDF (makes things easier if
plugins are implemented in multiple files).
You might want to look at how UncommonSQL and CL-SQL handle their
different database backends.
* Pieter
| How will a plugin type thing work on lisp?
The usual issues, loading binary code and making it possible for it to
call already loaded code, are trivial. The loading and linking phases
of Common Lisp environments are entirely transparent.
However, you need to think about how you wish to �register� your code
so that the system can call it. One common way to do this is via hook
variables -- lists of functions to call with no arguments and only for
effect at known points in the code. Another common way is to use CLOS
methods with :BEFORE, :AROUND, and :AFTER qualifiers. You need to
plan for either way. Other ways are possible, such as replacing a
function entirely, but then it may be difficult to load more than one
plugin that does this, even if you store the old definition in some
variable and call it at the appropriate time.
| In c++ I would make a nice base class with a bunch of pure virtuals.
| The .so or .dll will return a pointer to an instance of the base class
| and so the story goes. Is the approach in Lisp similar?
Generally, no, but you could certainly arrange for something like it.
--
Erik Naggum | Oslo, Norway 2004-033
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.