Method Combinators are still there, slightly improved from Zetalisp's Flavors and New Flavors.

The CLOS Standard Method Combination has primary, :before, :after and :around methods.

There are in CLOS also various 'simple' method combinations like AND (runs all applicable methods until one is false), OR, + (sums up the results of all applicable methods), PROGN (runs all applicable methods and returns the result of the last one). These seem to be rare in CLOS code.

> They made the code extensible, compact, and completely unpredicatable ...

That's kind of the point that one does not care which methods actually run and when - the 'system' takes care of that. Similar to, say, when you call REDUCE on a list - one does not know which elements are in the list at runtime. Or when you call a generic function on a bunch of instances - you know only at runtime which method runs - because of dynamic dispatch - the method combination feature adds a layer of complication to it. Like on a Lisp Machine where you can add a :before method to a window function and it's immediately active, because the method combination is recomputed. Or when one adds a mixin to a window class and the width of a window then has a different result, because the + generic function computes a new value, because a new method is available via the + method combination. You can scare a lot of people with this, though.

One can program full new method combinations in CLOS, like in Flavors. This might even be useful. ;-) An example is the integration of 'Design by Contract' methodology into CLOS. One can add a DBC method combination and then work with preconditions, postconditions and invariants somehow integrated into Common Lisp's condition system.

https://www.muc.de/~hoelzl/tools/dbc/dbc-intro.html

and newer:

https://github.com/sellout/quid-pro-quo

> That's kind of the point that one does not care which methods actually run and when

What is the right method for debugging? I've been trying to debug one particular issue in CL code (McCLIM + Climacs) and I've hit the wall in every direction that I tried to see which method was responsible with the issue I've seen.

A plethora of around, before and after in both composition and inheritance that I've lost my way. I've tried various depths of reading and runtime debugging with no significant success. It left me with the image that I should have the whole program in my head to be able to understand it.

It's usually the case that the solution is where you're not looking therefore my question is where (and in what way) should I look at the code to understand what it is supposed to do?

The debugging tools need to know about that. Usually you would look into the stack trace and see which methods has been called and editing the method object brings us to the source code. Best when things are NOT optimized for low DEBUG and high SPEED.

When I was working more with those things I wrote some browsers for browsing methods in CLIM and for MCL. The Lisp Machine should already have some tools, IIRC. LispWorks also has a generic function browser. One enters a generic function and argument types -> LispWorks shows which methods are used for those.

  FOO (FLOAT STRING) ->

  MULTIPLE-VALUE-PROG1
    CALL-METHOD
    (METHOD FOO (FLOAT T))
      (METHOD FOO (REAL T))
    CALL-METHOD
    (METHOD FOO :AFTER (T T))

Indeed, having good runtime debug tools is absolutely necessary for debugging dynamic objects [1].

I've come to this conclusion during this particular experience and I've confirmed it time and again. I've recently seen an older video of Gregor Kiczales on Aspect Oriented Programming and if I did not read in too much he emphasizes the same issue with proper debugging tools.

Thanks for the tip; it might be what I needed for me to download LispWorks and try again.

[1] Some kernel developers just don't get this even after you show them a call using a function pointer. Read the code they say. Right...

Been working on getting a CLIM codebase (that is older than ANSI CL standard) running under modern open source implementations (SBCL, CCL). This too was my primary problem. CLIM spec was written with CLOS in mind, and implementations tend to absolutely abuse CLOS and MOP. I spent many long hours untangling all the mixins introducing :around methods. Good runtime debugging is absolutely crucial for this kind of code - something which open source CL implementations do not really have. Even prettified by Emacs, the inspector can get you only so far. Hell, this is the only time in my life where SBCL itself crashed completely when I did simple "jump to symbol definition" in Emacs...

Typically your debugger will be a listener, so it's easy for you to write explanatory functions and in-the-moment expressions for unpacking what's going on. The latter is what I miss most whenever I end up in gdb.

In Flavors/Genera one has Zmacs commands: 'List Methods', 'Edit Methods' and 'List Combined Methods'. Similar functionality exists for CLOS - I think there is a 'Show CLOS Generic Function' listener command, or similar.

You are mixing method qualifiers (:before, :after, :around) with method combinations (progn, and, or, +, etc.) which are very much alive. For maximium fun, you can even define your own: http://www.lispworks.com/documentation/lw70/CLHS/Body/m_defi...