Live data from Hacker News

Common Lisp Object System (CLOS)

hescaide.me

61–70 of 90 posts

Re: Common Lisp Object System (CLOS)

#61
post #9

One thing bad is the word 'class'. What it is supposed to even mean? It was some fancy concept by stupid Normen when defining Simula. My Simula teacher said that you could just translate it as "design" as in "design of car and its implementation". Anyways Python's "class" is even worse: class c: a=10 print c.a c.a=13 print c.a I cannot think any English word to replace the "class". The word I am thinking of could be…

From https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...: ‘We chose the terms “class” and “objects” of classes for our new Simula. The notion of subclass was especially appealing to us, since we had seen many cases of objects belonging to different classes having common properties. It would be useful to collect the common properties in a separate class, say C to be specialised differently for different purposes, possibly in different programs.

It is about classifying objects. You want to have a shared definition for objects that share a common set of properties. Those objects constitute a certain class of objects, defined by their commonality. To specify such a class of objects, you specify those shared properties. This is what classes do in programming languages, they provide a specification of a certain class of objects.

If you know that a given object belongs to a certain class, you then know that is has the properties specified by the class. For example, if you know that an object belongs to the class of String objects, then you know that it has a length property (or whatever).

“Class” is very similar to “type”, except that “type” is usually more general. But in languages where everything (every value) is a object, “class” and “type” can be virtually the same.

Re: Common Lisp Object System (CLOS)

#62

Earlier quoted context omitted.

You absolutely can use it without CLOS. It was an afterthought poorly bolted on that was worse than its predecessor in most ways as to be portable. It didn't exist when CLtL1 was written and barely existed when CLtL2 was released.

Ok, I will try to use Common Lisp without the CLOS: * 123 123 That looks good, let's see... * (describe *) 123 [fixnum] Huh? What's a FIXNUM? * (describe 'fixnum) COMMON-LISP:FIXNUM [symbol] FIXNUM names the built-in-class # : Class precedence-list: FIXNUM, INTEGER, RATIONAL, REAL, NUMBER, T Direct superclasses: INTEGER No subclasses. Sealed. No direct slots. Uh-oh. Anyway, you see what I mean now by not being able t…

> Unless by using the CLOS you mean having to explicitly opt-in by using classes, multiple dispatch, multiple inheritance, generic functions, the MOP and all that weird stuff.

Yes, that's what I meant. The fact that the CL type system maps into the class system doesn't mean we all code OOP. If you want to argue semantics, sure..

SBCL will generate _very_ different code for fixnums vs general objects, so much so that claiming that (+ 1 2) is using CLOS makes no sense.

Re: Common Lisp Object System (CLOS)

#63

Meh.. I code in Common Lisp at home and Java professionally and I've never understood why people praise the CLOS so much. Like the author says, 99% of the time you don't have a reason to use OOP, and the few times you do you'd prefer to use as little as possible to keep everything sane. It's also one of the few parts of CL which are not optimized well by default, using structs or other basic data structures instead o…

> using structs or other basic data structures instead of objects has visible performance benefits in SBCL if you care about that for some reason.

Sure, but recall that CLOS really consists of two distinct components. The class/object system, and generic functions.

Since CLOS is baked into the CL type system, generic functions will happily dispatch against DEFSTRUCT types (as well as all of the other types, not just objects). Add the ability to :include other DEFSTRUCTS, and the idea that when DEFSTRUCT B :includes DEFSTRUCT A, then the type-of of B is both as a B struct and an A struct, then you get back alley inheritance using structures.

So, now (in theory) you get the efficiency of DEFSTRUCT, but all of the dynamic dispatch giddy goodness of DEFMETHOD, when and if you want to use it.

It can be a really nice compromise.

Re: Common Lisp Object System (CLOS)

#64

Earlier quoted context omitted.

Ok, I will try to use Common Lisp without the CLOS: * 123 123 That looks good, let's see... * (describe *) 123 [fixnum] Huh? What's a FIXNUM? * (describe 'fixnum) COMMON-LISP:FIXNUM [symbol] FIXNUM names the built-in-class # : Class precedence-list: FIXNUM, INTEGER, RATIONAL, REAL, NUMBER, T Direct superclasses: INTEGER No subclasses. Sealed. No direct slots. Uh-oh. Anyway, you see what I mean now by not being able t…

> Unless by using the CLOS you mean having to explicitly opt-in by using classes, multiple dispatch, multiple inheritance, generic functions, the MOP and all that weird stuff. Yes, that's what I meant. The fact that the CL type system maps into the class system doesn't mean we all code OOP. If you want to argue semantics, sure.. SBCL will generate _very_ different code for fixnums vs general objects, so much so that…

It makes sense to me. The same as claiming that doing `1 + 2` in OCaml is making use of the type system despite me not writing any type information and the language performing type erasure.

Re: Common Lisp Object System (CLOS)

#65
post #13

Earlier quoted context omitted.

"Object"? Though that creates ambiguity between definition and instances of the definition.

You just nailed it :) Maybe instead of "Class" and "Object" we should use "Definition" and "Instance".

Can I humbly suggest that it's definitions and instances 'all the way down'

Re: Common Lisp Object System (CLOS)

#66

I've been exploring CLOS for the past couple of weeks. From what I can tell, it seems especially nice for a system that needs extreme flexibility. I like to program MUDs and rougelikes as side projects, and after initial exploration, CLOS seems perfect for that - it can enable certain interactions that I would otherwise have to spend a lot of work and design achieving in other languages. It turns what feels like a ch…

I once made a rules engine for Magic the Gathering in python. As a design problem it is quite interesting since the key thing about MtG is that the pieces of the game can override the game rules. After reading about CLOS a few years later it seems I reinvented some of the main ideas (like cleanly re-entrant method combinators, cleanly overriding functionality of other objects in a way that can be reverted) using python's dynamiticity (especially descriptors which let you override what obj.[accesor] means).

Re: Common Lisp Object System (CLOS)

#67
post #2

Alan Kay’s immortal quote about OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... ] His reference to ‘LISP’ is, of course, referring to C…

> His reference to ‘LISP’ is, of course, referring to CLOS.

Definitely not. The all-caps "LISP" should be the strongest hint, but he name drops McCarthy and Carl Hewitt. McCarthy's LISP didn't have closures, so I'm thinking Alan is referring to something closer to Scheme. Which might make sense as Scheme is based on ideas from Hewitt (actors, message passing, etc.). But Alan isn't being terribly specific. You have to understand there are thousands of different "LISP" systems in the world. Many of which are just in some thesis or white paper.

Re: Common Lisp Object System (CLOS)

#68

Earlier quoted context omitted.

> Unless by using the CLOS you mean having to explicitly opt-in by using classes, multiple dispatch, multiple inheritance, generic functions, the MOP and all that weird stuff. Yes, that's what I meant. The fact that the CL type system maps into the class system doesn't mean we all code OOP. If you want to argue semantics, sure.. SBCL will generate _very_ different code for fixnums vs general objects, so much so that…

It makes sense to me. The same as claiming that doing `1 + 2` in OCaml is making use of the type system despite me not writing any type information and the language performing type erasure.

[deleted]

Re: Common Lisp Object System (CLOS)

#69

Meh.. I code in Common Lisp at home and Java professionally and I've never understood why people praise the CLOS so much. Like the author says, 99% of the time you don't have a reason to use OOP, and the few times you do you'd prefer to use as little as possible to keep everything sane. It's also one of the few parts of CL which are not optimized well by default, using structs or other basic data structures instead o…

> using structs or other basic data structures instead of objects has visible performance benefits in SBCL if you care about that for some reason. Sure, but recall that CLOS really consists of two distinct components. The class/object system, and generic functions. Since CLOS is baked into the CL type system, generic functions will happily dispatch against DEFSTRUCT types (as well as all of the other types, not just…

Generic functions in Common Lisp dispatch against "all the other classes", not "all the other types". Every class in CL is a type, but not every type is a class.

Re: Common Lisp Object System (CLOS)

#70
post #2

Alan Kay’s immortal quote about OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... ] His reference to ‘LISP’ is, of course, referring to C…

That reminded me of Peter Norvig's comment:

> Depending on your definition, CLOS is or is not object-oriented. It doesn't support encapsulation.

Lack of encapsulation would preclude the protection and hiding of state-process.

Post reply on HN