Re: To CLOS or not to CLOS?

On 20 Feb 2007, at 21:31, [email protected] wrote:

>> I think if Graham spent a good chunk of time working on a CLOS  
>> project
>> that he, too, would come around to the point of view that CLOS is a
>> significant achievement.
>
>     I can agree with all of the good things you say about CLOS; but  
> the
> interesting (to me) bit is, what could be done better?  For example:
>
> - Are generic functions really the right or only way to go?  It  
> seems many
> of CLOS's advantages could still be had in a object-dispatched object
> system designed with a similar mentality, and perhaps there are  
> advantages
> to object-dispatch.

Perhaps there are. But I don't know any. ;)

Maybe you should be more concrete here.

> - Is the syntax and verbosity really as simple as can be without
> sacrificing functionality?

No, it's most certainly not. But it's pretty close, and from a  
functionality point of view not worth the effort to make deep  
changes. [1]

>     For example, someone mentioned passing state in method calls  
> that in
> an OO system would be stored in the object.  That seems like a strike
> against generic-based OO (GOO?).  This issue references both points
> above.

I don't know what you are referring to here. Could you clarify (maybe  
by providing a link)?

> - Other things I missed that experienced CLOS users would criticize or
> improve if they could?

Sure:

+ The CLOS MOP (which is not part of ANSI Common Lisp) is  
underspecified. It works relatively well for practical purposes, but  
could definitely be improved. There are also a few holes in the CLOS  
MOP, for example in the generic function invocation protocol, that  
should be fixed.

+ Some parts of the main CLOS specification in ANSI Common Lisp could  
use some minor revisions. Off the top of my head:
- CLOS misses a way to declare the method class method-class options  
in a defmethod form.
- ANSI CL specifies that parameter lists in function definitions and  
in function invocations should match, and that a compiler is allowed  
to signal errors if they don't. It should be possible to relax this  
requirement to be able to pass extra arguments to methods under the  
hood.
- The define-method-combination form is a little bit overspecified.  
The declarative method group specifiers are not really necessary -  
any iteration or list comprehension macro would be fine as well here.  
There is also a requirement to signal an error when two methods "play  
the same role and their order matters" which is rather inconvenient  
(and I don't understand what the rationale here is).

These were issues I had to face in some cases. However, none of them  
were really serious - it was always possible to work around them.

It's also the case that the CLOS MOP specification is based on a  
somewhat "traditional" understanding of how to achieve efficiency in  
OOP languages. It would be an interesting research topic to come up  
with a MOP that would, for example, be compatible with polymorphic  
inline caches, or similar techniques. Jonathan Bachrach's work on  
generic dispatch seems like a pretty good starting point here - see  
http://people.csail.mit.edu/jrb/Projects/partial-dispatch.htm - a MOP  
for that would be quite nice. (However, again I don't think this is  
such a fundamental issue in practice.)

It may also be interesting to incorporate some ideas of mirror-based  
reflection (basically, by turning class-of into a generic function).

In other words, what CLOS needs is a little bit of polish, but that's  
about it. ;-)


Pascal


[1] You have to take into account here that a lot of engineering  
effort went into the design of CLOS. I would actually count in its  
direct precursors (Flavors, LOOPS, CommonLoops and NewFlavors) here.  
It would be a major undertaking to make fundamental changes, for  
probably very little gain in expressive power.

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium