Carl Mäsak

> I should probably study CLOS more. I'm now reading through [The Common Lisp Object System: An Overview](https://www.dreamsongs.com/Files/ECOOP.pdf); it feels very relevant and well-written. > In the generic function approach,...

And yes, on page 11 of that text, it's confirmed that CLOS uses the same terminology as Dylan: methods belong to generic functions, rather than classes. I'm a bit divided....

Definitely need to try this in a branch. My feeling right now is that generic functions would be a good fit for 007. I do enjoy the idea of making...

[This post](https://axisofeval.blogspot.com/2010/05/revisiting-multimethod-dispatch.html) is interesting, and signals that we'll want to be very careful with implicit behavior around candidate matching. CLOS and Dylan seem to be fine with "do some best-effort...

Also worth pointing out. If we switch to generic functions, we'll largely back out of the changes made in #111.

I started writing something here about methods and closure semantics, but before I got to the end I had contradicted myself. It's... weird. I need to think about it more.

Ok. I think the only sane model is for _all_ methods lexically nested under a generic function to be visible/callable via the generic function. Regardless of whether a particular method...

Or maybe not... My falling-asleep thought yesterday was "what about when a generic function is imported from a module?" We can't just destructively update that module's generic function with new...

In other words, the generic function of a method is always declared in the same scope. It in turn has prototypical links to same-named generic functions in outer blocks or...

In the fullness of time, these become _highly_ inlineable. Once we've computed the poset cache for a generic function, we can inline it as a sequence of boring `if` statements...