Good LISP steals?

Brian T. Rice water at
Wed Apr 17 08:14:48 UTC 2002

Hey, I've been working on the Slate language idea for a couple of years 
in this direction, and I still don't have a full implementation that's 
simple enough, so there's your warning. Now here are my thoughts...

On Wednesday, April 17, 2002, at 01:27 AM, goran.hultgren at 

> There are a few LISPers on this list and I Schemed in school and liked
> it a lot. :-)
> My personal view is that I am aware that CLOS probably is the most
> advanced OOP (well, there may be others much less known and thus rather
> irrelevant, like Beta for example which made my head spin) but I always
> get overwhelmed by it all (small is beautiful IMHO).

CLOS doesn't have an *incredible* amount of benefit beyond Smalltalk, 
but it has different assumptions about what OOP is about that allows it 
to do what Smalltalk can't. The primary example is multiple-dispatch 
(and, no, I don't mean generic functions; those are to abstract on 
method collections to the Lisp level). Lee Salzmann has been kicking 
around the idea of multiple-dispatch in Smalltalk-style syntax, and 
there may just be a way to extend our current class definitions to 
account for it without an enormous amount of overhead. If you're curious 
as to what the savings are, consider every place in a method where you 
conditionalize on any aspect of your argument. Lisp's type system allows 
for predicates to be used as types, so all of that would be complexity 
out the window if you could make reify Smalltalk classes for blocks as 
predicates. Actually some of the work I've done suggests that this is 
not hard in Smalltalk at all.

The big win, though, is that you find a much reduced need for 
refactoring. If I have a Smalltalk method centered on class A which also 
depends heavily also on class B, a Smalltalk programmer looks and 
wonders where it belongs, and it's a book topic all of a sudden (I own a 
copy of _Refactoring_ by Fowler, btw). With multi-methods, this is a 
non-issue; the catch is that Smalltalk *does* respect an object's 
privacy, and CLOS doesn't, so private variable access is the rub, but 
not a show-stopper.

The major problem is that the design of tools in Smalltalk is primarily 
class-centered. The way to side-step this is that multi-methods can be 
specified by one class arbitrarily by using a dictionary saying "these 
are methods where I appear in the second argument position". This is 
Lee's idea, and he has an algorithm prototyped which handles that kind 
of dispatch setup fairly well.

What can't we steal from Lisp/CLOS? Optional and keyword arguments come 
to mind. Of course we have keyword syntax and ways to set options (as 
variables) in objects, but Smalltalk has the before and after problem 
that you can't just "stick in" the keyword or argument within another 

What shouldn't we steal? A big thing that I think I should warn you 
about is that :before, :after, and :around methods and similar 
modifications don't really get you much that you don't already have with 
"super" sends. Beta has an inner clause (which is like inverted 
super-sends), but squeak can also handle abstract methods which do 
enough of the same thing. It wouldn't be worth it.

> Anyway, there are surely quite a few good things in the LISP world that
> might perhaps be possible to steal into the Squeak world. I hate
> "featuritis" like anyone, especially in a language, but it is possible
> to add stuff to Squeak without having to resort to changing the
> language.
> Exceptions is a good example I think - sure, I don't know what it took
> under the covers to get them in, but from a developer's view it's just
> plain objects and messages. So that addition was a good example of
> getting a good "language feature" into Squeak/Smalltalk without adding
> to the language.

Or it could be a library feature. Tim Olson made a really good 
suggestion in the "control flow of looping thread" to make new kinds of 
block-handling methods which I thought an excellent direction to go in 
(BTW, that's  my vote for including that and similar ideas as permanent 
ENH's). What's not immediately obvious from such suggestions is how 
widely spread their application could be across the image. I think it 
would be phenomenal overall.

Some idioms that Squeak can handle, but I have only seen in my own code 
is to write accessors and mutators that protect their data, such as 
blocking all mutations after the initial one (just check your slot for 
nil), or cloning the object and putting the mutation there. This can be 
automated by writing methods accessible from menu's that generate a 
given kind of accessor/mutator pair. Another more common idiom is lazy 
accessors. (I've done everything but the menu-hacking.) The refactoring 
browser has hooks for a decent amount of that, but apparently it's 
either not worth the effort of the grokking coders to port it for 
whatever reason (probably good ones like "paying the mortgage" and 
"having a life" :).

> Enough blabbering, over to you LISPers - what could/should we steal? Or
> is there nothing good worth stealing?

Not at all. My final note is about the tools we use, which relates to 
the *DUM DA DUM* CLOS MOP that everyone gets so excited about when they 
discover it (I definitely did, but this was in '94). My biggest idea has 
been that the menus don't really reflect any kind of conceptual 
structure, which only when I just read your post did it (recently) occur 
to me that it specifically relates to the lack of a MOP. What I mean is 
that we could include things like objects for reifying slots themselves, 
or separate the object structural information from itself (Kent Beck in 
the back of the _Ordered Collections_ book recommends a MetaObject 
refactoring of just this kind). (Right now, you can use such methods on 
any object to "hack" in it, breaking abstraction.) This isn't as 
necessary though as making menus that support the concepts, so that I 
can manage slots by clicking on a list(Morph) of slots in the current 
class and get more than "methods calling this instVar". This is just a 
small example that comes to mind, though. I also just recalled that 
MetaObjects can be used to encapsulate both the dependents mechanism and 
the mutation protection I mentioned above.

The last thing to mention is fine-grained factoring and how much of a 
Big Win it can be if you have the right philosophy about it. <rant>This 
mostly relates to Squeak's experimental tools like Morphic and such. 
(Yes I consider Squeak's Morphic an experiment.)</rant>

> regards Gˆran

I hope this wasn't too much for you ;)

P.S. There's a lot more where that came from, and it would be nice to 
finally get these ideas going in Squeak while Slate is still racing 
around the design-prototype loop.

More information about the Squeak-dev mailing list