I'm looking for concrete examples of (Common) Lisp's dynamicism, more
precisely with respect to one's ability to manipulate/modify the code
in a running Lisp image. I'm trying to understand how Lisp differs, if
at all, from similar features which are believed (by some Java
developers) to be present in certain Java environments, or at least
achievable with minor tweaking/hacking.
I found on /. a most interesting description of this Lisp capability,
given by Kent Pitman, but I'm looking for something more detailed.
Do Java and Lisp differ in this respect, and if so, how? Any reference
would be welcome.
Regards.
·······@mac.com (Olivier Drolet) writes:
> I'm looking for concrete examples of (Common) Lisp's dynamicism, more
> precisely with respect to one's ability to manipulate/modify the code
> in a running Lisp image. I'm trying to understand how Lisp differs, if
> at all, from similar features which are believed (by some Java
> developers) to be present in certain Java environments, or at least
> achievable with minor tweaking/hacking.
>
> I found on /. a most interesting description of this Lisp capability,
> given by Kent Pitman, but I'm looking for something more detailed.
>
> Do Java and Lisp differ in this respect, and if so, how? Any reference
> would be welcome.
- - - - -
There's the basic ability to add methods to an existing generic function
dynamically without clobbering existing methods.
- - - - -
In a "method call" in java like foo.bar(x,y,z), java does dynamic
dispatch on the type of foo, but static method selection based on the
compile-time type of x,y,z. CL syntax for this is (bar foo x y z) and
there is complete symmetry in the dispatch of foo, x, y, and z. That
is, all involve dynamic dispatch. So if the code doing the call has
no type information about x, y, and z it will still get specialized
methods for those objects [as it should]. This means you can compile
a function like:
(defun foo (x y) (bar x y))
in total isolation, not knowing the type of x or y and still not impede
correct dispatch. If you later kadd methods (using the dynamic method
addition capability I mentioned) you get:
(defmethod bar ((a integer) (b integer)) (+ x y))
(defmethod bar ((a integer) (b float)) (- x y))
And any calls like the following will now yield the indicated results
(whether such calls were compiled before or after these method additions).
(foo 3 4) => 7
(foo 3 3.0) => 0.0
In Java, you can't even compile FOO above, whether or not you have the
later definitions of bar, because it will try to do x.bar(y) and it will
notice there are no type declarations (or that the type declarations are
overbroad if you've given Object), and so you just can't go on.
Lisp uses this facility extensively to allow later modules to add
methods for certain operations and to have earlier modules see the
update. In Java, the very definition is that later loading must
_not_ see updates due to later loading of new methods. That's
the essence of "static".
- - - - -
Another example of dynamicity is the ability to make instances of a class,
then redefine the class (in the running image where the images exist),
and have the existing instances automatically upgraded to accomodate the
new class definition without having to restart Lisp.
- - - - -
Another example is the ability to construct code and to call the compiler
at runtime in order to have code build more code. Further, we can load
new definitions of functions into a system and old code that was calling
the old definitions will see the new definitions. This is useful for
patching running images.
- - - - -
There are probably other examples -- these are just the ones that popped
into my mind on short notice.
Are these kinds of examples helpful? I've thankfully had the luxury of
ignoring Java for the last few months, so my memory of it is slightly rusty
and I apologize for that.