libera/#commonlisp - IRC Chatlog
Search
9:48:35
akater[m]
Yesterday I had a little conversation about CLOS usage in Emacs. And I formulated something I've been thinking about for a long time. The purpose of Lisp object systems — at least Flavors and CLOS — is to enable modular design via flexible and predictable code reuse. When you don't reuse code by means of inheritance and don't see how and why it would happen, there is no point in using CLOS, at all. Agree?
9:51:24
semz
Code reuse need not happen through inheritance specifically, generic functions can do that just fine.
9:53:10
beach
akater[m]: Also, people may avoid code reuse and may fail to see how and why it could happen, out of ignorance. Ignorance is a bad excuse for avoiding CLOS.
9:54:12
White_Flame
especially since CLOS goes way more powerful than typical simplified object systems
9:54:58
semz
I'd actually say that inheritance is the most overrated aspect of OOP. I rarely ever find myself using it. There's also the aspect that classes are redefinable at runtime while structs are not, but this is more of a CL quirk than anything general.
9:56:35
borodust
etimmons: hmm, it seems for quicklisp type of a source, clpm expects there to be present *-versions.txt file
9:57:51
hayley
Inheritance is one way to get mixins, which are underrated (though perhaps over-represented in CLOS).
10:00:27
hayley
I admit I made too much spooky action at a distance for myself by using :after methods to achieve some sort of "reactive" programming. But it was only a problem because I need the behaviour of a concurrent program written down in (close to) one place so that I can model it.
10:01:52
mfiano
I think the most under-used CLOS feature is progn method combination. I rarely see that used in codes that are not my own. Maybe it is just too domain-specific...idk, but I use it all the time.
10:02:51
hayley
Seems I have used progn to implement hooks for STOP-CONNECTION <https://cal-coop.gitlab.io/netfarm/documentation/decentralise2.html#%28idx._%28gentag._2%29%29>
10:05:03
beach
mfiano: https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Meter/meter.lisp
10:05:18
hayley
If I ever feel like writing it, I'll eventually get to the third iteration of my node software, which hopefully should be space efficient first (we need to check the transitive closure of objects but only temporarily) and then hopefully time efficient.
10:06:05
hayley
Been thinking I should test software transactional memory at that layer. If I use a SQL database properly, I would be marking out transactions somewhere anyway.
10:06:35
mfiano
Very nice. For me, progn combination is so useful that it is probably my favorite feature of CLOS. It comes in useful far too often for me, and I don't know of a comparable feature in any other object system.
10:07:15
beach
Here, we use the APPEND method combination: https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Input-output/io.lisp
10:08:24
beach
Features like that are rarely used, like macros, but when you need them, they are totally essential.
10:16:37
akater[m]
White_Flame: Dispatch is useful but it doesn't require CLOS. When only a single method is ever going to be applicable per gf call, you may just as well roll your own interface to recompiling a defun. I think I'd do that without thinking twice.
10:17:59
beach
And with generic functions, the methods don't have to be physically in the same place.
10:20:26
beach
akater[m]: PRINT-OBJECT is an example of a generic function where typically a single method is applicable for every call, but it is totally essential for application code to be able to add a method to it, without editing a global function.
10:24:44
akater[m]
beach: With print-object, it's trivial to imagine a use case for :before or :after method
10:27:21
akater[m]
All right, we seem to disagree. CL is missing a simpler inheritance-less dispatch — for legit reasons, I think (there's likely no single good enough design for this) but it is this fact that gives rise to one “Let's make all functions generic!” attempt after another. Meanwhile, people will keep writing such dispatching mechanisms (an reasonable ones) because they want expressive user-space optimization, dependent types and so on.
10:27:46
beach
I think you understood that when I mentioned PRINT-OBJECT, I was giving an example of a generic function with many methods, where typically only one is applicable, but where each method belongs to a totally separate "module", so that it is not reasonable to modify a global definition.
10:29:10
hayley
I disagree that any "user-space optimization" is any good, even if we limit ourselves to dispatching without inheritance. Merely inlining methods based on type inference with no regard for handling redefinition is definitely a step down.
10:31:25
hayley
Hot take: most of the perceived performance benefits of limiting dispatch techniques are disproven by reading up on the Self compiler. 30 years old isn't old enough to be conventional "wisdom" I guess.