Good LISP steals?
Brian T. Rice
water at tunes.org
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 bluefish.se
> 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
> 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