Question

I read ESR’s essay named “How to become a hacker?” several years ago (link can be found in my profile) and Eric suggested learning LISP. Well I’m learning LISP for quite a while and I like it so much that I decided to write a web application using it.

Since I’m using Spring for a while I think that it’s a good idea to write decoupled components and glue them together using an IoC container and depencency injection. I did a power search on google and it turned out that there is no such idea implemented in LISP. Do I miss something? Is there a good implementation of this concept in LISP or there is no point using it for some reason which is not yet clear to me?

Answer 1

‘Inversion of control’ is widely used in Lisp. It’s totally simple, since functions and closures are first class objects.

Dependency injection is trivial. Classes and functions can be configured via symbols and first class classes.

You usually don’t need a ‘framework’ for IoC or DI in Common Lisp, since a lot of functionality to configure and parameterize applications and libraries is built in.

‘first class’ means that something can be stored in variables, passed as arguments or returned as results.

In a language like Common Lisp, functions and classes are first class objects. Plus for decoupling via late-binding, you can use symbols as their names instead. The Common Lisp Object System knows meta classes and symbols as names for classes. Even generic functions and methods are objects and have meta-classes.

If concurrent-secure-server is a class and default-response is a function, you can do for example:

(make-instance 'web-services
               :server-class 'concurrent-secure-server
               :default-response-function 'default-reponse)

Above uses the symbol as the name for the class and the function. If the function gets a new version, the web service might call the new one later.

Alternatively:

(make-instance 'web-services
               :server-class (find-class 'concurrent-secure-server)
               :default-response-function #'default-reponse)

In above case we pass the class object and the function object.

In Common Lisp software modules can have global variables, which you can set with the right information:

 (defvar *default-server-class* 'concurrent-secure-server)

Alternatively you can set those in slots of like below.

(defclass server-object ()
  ((default-response-function
      :initarg :default-response-function
      :initform *server-default-response-function*)))

(defvar *my-server*
   (make-instance 'server-object
                  :default-response-function 'my-default-response-function))

You can even create objects and later change their class in a configuration phase.
The Common Lisp Object System allows you to change classes and have existing objects to be updated.

If you create an instance, you can be as flexible as you want:

• you can pass in the class
• you can pass in the arguments

Like this:

(let ((my-class 'foo-class)
      (my-args  `(:response-function ',*some-reponse-function)))
  (apply #'make-instance my-class my-args))

Sometimes you see Lisp libraries which are computing such arguments lists at runtime.

Another thing where you can configure Lisp applications at runtime is via generic functions. Generic functions allow :before, :after and :around methods – they even allow your own custom call schemes. So by using your own classes inheriting from other classes and mixin classes, the generic function gets reconfigured. This is like you have basic mechanisms of Aspect-oriented programming built-in.

For people interested in these more advanced object-oriented concepts, there is some literature by Xerox PARC, where these issues had been researched when CLOS was created. It was called ‘Open implementation’ then:

http://www2.parc.com/csl/groups/sda/publications.shtml (original link, now stale)

Archive:

https://web.archive.org/web/20110906111530/http://www2.parc.com/csl/groups/sda/publications.shtml

In the Open Implementation approach, modules allow their clients individual control over the module’s own implementation strategy. This allows the client to tailor the module’s implementation strategy to better suit their needs, effectively making the module more reusable, and the client code more simple. This control is provided to clients through a well-designed auxiliary interface.

One thing you don’t need: XML. Common Lisp is its own configuration language. Writing extensions for easier configuration can for example be done via macros. Loading of these configurations can be easily done via LOAD.