0

I am reading the Wikipedia article about CLOS.

It says that:

This dispatch mechanism works at runtime. Adding or removing methods thus may lead to changed effective methods (even when the generic function is called with the same arguments) at runtime. Changing the method combination also may lead to different effective methods.

Then, I inserted:

; declare the common argument structure prototype
(defgeneric f (x y))

; define an implementation for (f integer t), where t matches all types
(defmethod f ((x integer) y) 1)

Using SBCL and SLIME, I compiled the regions with code and had the following result:

CL-USER> (f 1 2)
1

Then, I added to the definition:

; define an implementation for (f integer real)
(defmethod f ((x integer) (y real)) 2)

Again, I repeated the process compiling the new region and using the REPL to eval:

CL-USER> (f 1 2.0)

2

First question, if CLOS had the opposite behavior of run-time dispatch (compile-time dispatch, I suppose), what would the result be?

Second question, I decided to comment out the second method, leaving just the generic function and the first written method. Then, I re-compiled the region with Emacs.

When calling the fuction fin the REPL with (f 1 2) I thought I would get 1 since the second method is out. Instead, I got 2.

CL-USER> (f 1 2.0)

2

Why did this happen?

The only way I can get back to (f 1 2) returning 1 is re-starting the Slime REPL and compiling the region (with the second method being commented out). Third question, is there a better way to have this result without having to re-start the REPL?

Thanks!

Pedro Delfino
  • 2,421
  • 1
  • 15
  • 30

1 Answers1

3

These two are actually the same question. The answer is: you are modifying a system while it is running.

  1. If CLOS objects weren't re-definable at run-time, this would simply not work, or you'd not be allowed to do that. Try such re-definitions with basic structs (i. e. the things you get when using defstruct), and you will often run into pretty severe warnings or even errors when the change is not compatible. Of course, structs have other limitations, too, e. g. only single dispatch, so that it's not so easy to make an exactly analogous example. But try to remove a slot from a defstruct.

  2. Just commenting out some source code doesn't change the fact that you evaluated (compiled and loaded) it before. You are manipulating a running system, and the source code is just that: source. If you want to remove a method from the running system, you can use remove-method (see also How to remove a defmethod for a struct). Most Lisp IDEs have ways to do that interactively, e. g. in SLIME using the SLIME inspector.

Svante
  • 50,694
  • 11
  • 78
  • 122
  • Thanks! Look, I commented out the second version of the method AND I re-compiled the first version of the method. They have the same name. Thus, I thought the REPL would use the first version, not the second. Why isn't that the case? – Pedro Delfino Mar 07 '22 at 17:11
  • 1
    @PedroDelfino: the name is the name of the generic function: methods don't have names. Until and unless you actively remove the second method from the generic function by `remove-method` it's still there. In particular reevaluating a `defgeneric` form does not make a new generic function: it may modify the existing one. Still less does reevaluating a `defmethod` form: if it did it would be impossible to ever add methods to existing generic functions. – ignis volens Mar 07 '22 at 17:21