CLOS: Integrating Object-Oriented and Functional Programming (2004) [pdf]

https://dreamsongs.com/Files/clos-cacm.pdf

by mepian • 3 years ago

122 87 3 years ago

galdor• 3 years ago

For anyone finding CLOS interesting, "The Art of the Metaobject Protocol" is the next logical step. A good way to dig deep into how CLOS is built.

It should be a mandatory read for anyone looking to design a programming language with object concepts.

rileyphone• 3 years ago

Agreed - another good resource is the original Flavors paper. Many of the parts are there like multiple inheritance and method combination but without the MOPs and multiple dispatch.

https://www.softwarepreservation.org/projects/LISP/MIT/nnnfl...

EdwardCoffin2• 3 years ago

I think I'd recommend reading Sonya Keene's Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS first though. I really don't know any other ways of learning all the things like method combinations and the like that make the MOP so powerful. All the CLOS tutorials I am aware of lack a real discussion of these features of CLOS.

mikelevins• 3 years ago

Agreed. It's easier to learn how to do practical programming with CLOS from Keene's book. AMOP is more useful for those who want to know more about how things work under the hood, or who maybe want to build their own implementation of CLOS or something similar, and easier to understand after you've absorbed Keene.

r95506842• 3 years ago

unrelated to your point, Sonya keene's book is the only one I know that was authored and typeset using Symbolics's in-house publishing system Concordia. (besides symbolics documentation sets of course)

Concordia (and its display component document examiner) had a pretty novel hypertext approach to authoring. all the content was made up of individual notes, that you could link together either with explicit links, or implicit one-follows-the-other links. I don't know if that's how Sonya used it, but when I authored some documents using Concordia, I discovered that it was very easy to focus on addressing specific points in almost a throwaway fashion. write a note on some subject you want to address. if you don't like it, write another take on the same subject. now you have the option to put either note into the book flow, refine them in parallel, and defer editorial decisions to the very end. the process is very reminiscent of explorative programming in lisp, so in other words symbolics people figured out how to write books in the same way as they write their code. ultimate vertical integration.

Jach3• 3 years ago

The book "Object-Oriented Programming: The CLOS Perspective" is a better intro than just diving into AMOP. It's essentially a collection of papers, but it really helps contextualize a lot of the early design thinking, gives a gentle introduction to the MOP, compares CLOS with other languages including C++, and showcases some application uses back then.

jauntywundrkind• 3 years ago

One of the core points about metaobject protocols is that while it's important to language design, a good language to me also exposes & makes flexible the object system to users of the language too.

From a review (https://www.adamtornhill.com/reviews/amop.htm),

The metaobject protocol behaves like an interface towards the language itself, available for the programmer to incrementally customize. Just as we can specialize and extend the behavior of the classes we define in our own applications, we can now extend the language itself using the very same mechanisms.

One of the points that has rather surprised me is that we devs have not more broadly explored what we could do with our metaobject protocols. We havent had a boom in metaprogramming, we haven't seen a largescale return of AOP; we've been letting objects stay dumb unextended objects for a long time now.

The one sizable exception I have on my radar is React's Higher Order Components, where components/classes were wrapped/composed in other classes. Slices of object behavior were spliced into place.

Now that's replaced with hooks, which invert the relationship, making the function up front composed all behavior it might want as hooks that it calls.

I don't know enough about how Rust macros are made & used. My vague impression is they are very scarcely considered. Maybe I just missed the discussions but I'd expect there to be lots of blogging about this topic if metaprogramming here was really as fertile a field here as to be expected.

jmeister• 3 years ago

You might find this interesting:

Metaobject Protocols for Julia https://drops.dagstuhl.de/opus/volltexte/2022/16759/pdf/OASI...

travisgriggs• 3 years ago

One of the points that has rather surprised me is that we devs have not more broadly explored what we could do with our metaobject protocols. We havent had a boom in metaprogramming, we haven't seen a largescale return of AOP; we've been letting objects stay dumb unextended objects for a long time now.

The other day I showed some newer devs how they could replace a good 10+ lines of for/index/loop/conditional code whose purpose was to find either the next or previous elements following an element that matched a condition with wrap around semantics. I did it using a zip and a filter. Good old “functional” approach. That’s cool they said, and then got rid of me as quick as they could. They had been close to pushing their changes. And indeed did.

It used to be the case that a sizable number of my peers were interested in furthering their craft. Those that “just ship it, it works, ok?” We’re tolerated. Now it seems that enthusiast peers that are interested in “exploration” and “discovery” are few and far between. I’m surrounded by people that do their hours and clock out tickets.

So no, I am no longer surprised by this lack of meta programming interest. Or any other “higher level” linguistic pursuits.

pjmlp2• 3 years ago

We havent had a boom in metaprogramming, we haven't seen a largescale return of AOP; we've been letting objects stay dumb unextended objects for a long time now.

As user of Java, .NET and C++ ecosystems, I beg to differ, those subjects are quite present.

lispm10• 3 years ago

A bit more from RPG about CLOS:

https://dreamsongs.com/CLOS.html

The CLOS spec was a collaboration of:

Linda G. DeMichiel, Richard P. Gabriel (short RPG) : both from Lucid, Inc.

Sonya E. Keene, David A. Moon : both from Symbolics, Inc.

Daniel G. Bobrow, Gregor Kiczales : both from Xerox PARC

The actual CLOS Specification:

https://dreamsongs.com/Files/concepts.pdf

https://dreamsongs.com/Files/Functions.pdf

Published here: https://dl.acm.org/doi/10.1145/885631.885632

There is also a CLOS MOP spec, but that's not a part of the Common Lisp standard:

http://lispm.de/docs/Publications/Lisp%20Language%20Manuals/...

pmoriarty• 3 years ago

Do any of the languages that are popular today have object systems that are as powerful and flexible as CLOS?

messe• 3 years ago

Julia, perhaps? Although calling it popular is a stretch maybe. Its multiple dispatch system is even more ingrained to the language than CLOS (all functions are generic by default). It's very much a Lisp in Matlab's clothing.

cmrdporcupine• 3 years ago

... ish? There's a lot of furniture that's bolted into Julia's runtime in terms of task management and so on, that isn't really like a Lisp runtime? It doesn't have that same "It's Turtles All the Way Down" self-consistent vibe that a Lisp has.

On paper Julia looks like a great piece of kit. Once I worked in it professionally for a couple months, it started to leave a bad taste in my mouth.

pjmlp2• 3 years ago

Julia, as answered on the sybling comment.

Clojure has a subset, and I guess Racket is quite flexible with its language modeling framework.

Going on an edge, C++ is also quite flexible when one looks beyond of plain classes, and combines them alongside type parameters in templates, and compile time reflexion via template metaprogramming and concepts (although it is quite clunky).

drnewman• 3 years ago

Ruby has a meta object protocol. The net effect of the language isn't as powerful as Common Lisp since you don't have code-as-data in method definitions, but Ruby's object system is comparably powerful as CLOS (though made in the image of Smalltalk) it comes with a meta protocol for methods, objects, classes, modules, even lexical variables.

https://ruby-doc.org/3.2.2/Object.html

https://ruby-doc.org/3.2.2/Method.html

https://ruby-doc.org/3.2.2/Class.html

https://ruby-doc.org/3.2.2/Module.html

https://ruby-doc.org/3.2.2/Binding.html

whartung• 3 years ago

I essentially use "abbreviated" CLOS.

In CL, defstruct structures walk on both sides of the CLOS line. They're not as robust as full boat CLOS classes, but they're not just a bag of fields either. They fully participate in CLOS dispatch, you can do composition with defstruct, you can create custom constructors and such. So, they fit right in with many "dumb object", or perhaps "slightly clever object" use cases without all of the wordiness of a full CLOS class.

Mind, I'm not an experience CLOS user. I'm not choosing defstruct over defclass for any other reason save that I find it less verbose and it offers the functionality that I need. I'm sure my code might be idiomatically different were I to use true CLOS classes instead of defstructs, but I can't say right now that I'm "missing" anything.

But I do think it's cool that defstructs participate very well with CLOS and that's it's not a "my way or the highway" type of system, it just integrates really well with the rest of CL.

lispm10• 3 years ago

They're not as robust as full boat CLOS classes

Structures support single inheritance, CLOS classes support multiple inheritance. The main reason for structures is that they are faster to use by default - but they are less flexible. For example: CLOS classes support updates of existing objects when the class definition changes, structures don't support updates.

pfdietz4• 3 years ago

My feeling on this is that Common Lisp implementations should support classes in a way that idiomatic usage is just about as fast as structures. This is nontrivial, but I think it could be done.

EdwardCoffin2• 3 years ago

On the related subject of the Meta Object Protocol, Gregor Kiczales talked at a meeting of the Vancouver Lisp Users Group in 2006, which they called a MOP retrospective [1]. He gave some thoughts on subjects like why more recent languages don't have MOPs. The link below is to archive.org's copy of the page and the .ogg recording of the talk along with Q&A throughout and after.

[1] https://web.archive.org/web/20060821003818/http://bc.tech.co...

7thaccount2• 3 years ago

I'm not a hotshot developer, but I'd guess a lot of recent languages (e.g. golang) are more structured around how to keep things simple (not necessarily easy) and uniform to where there aren't many surprises for new developers and the company can more or less turn coding into something more like an assembly line (to use an overly simplistic metaphor).

Contrast that with languages like Lisp with crazy amounts of flexibility that really cater to small teams of rockstar developers (to use another overly simplistic metaphor) and you can see the problem. Most companies want the former and not the latter.

leetrout3• 3 years ago

I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work.

Horses for courses - I will never be a language designer / developer with this attitude.

ecshafer• 3 years ago

Go was made popular and successful for only one reason, google used/made it. And this was at the height of googles coolness. So other companies followed on the bandwagon, or were made by former google developers and brought it over. The success is completely secondary to how many people like go or the features it has.

As far as simplicity I think I would disagree and agree with that. Rust is not a simple language. Other languages like F# or Scala or Kotlin that have arisen in the same timeframe as go are also not simple. But they do try and make some hard things easier, like concurrency or type safety.

wtetzner6• 3 years ago

I don't really buy into this view of Go. Go doesn't keep things simple and uniform. It's more limited in many ways than other languages, but it's feature set is largely arbitrary, and not particularly simple. Limited and simple are not synonyms.

gleenn2• 3 years ago

People tend to say Lisps cater towards smaller dev shops. Clojure spends a lot of time trying to keep things simple though. They are relatively opinionated about a lot of stuff. I've seen some relatively large projects with a lot of devs using it too. So I don't think your statement is universally true

FpUser• 3 years ago

There is a big difference between "a lot of recent languages" and "golang".

Also Google solves Google's problems. They do not give a fuck about rest of the world. If what they do helps you personally then adopt it. If not let them go play hide.

CLOS: Integrating Object-Oriented and Functional Programming (2004) [pdf]

Related Stories