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?
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))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...
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