Alan Kay wrote:

> The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
> [snip]
> If you focus on just messaging -- and realize that a good metasystem can
> late bind the various 2nd level architectures used in objects -- then much
> of the language-, UI-, and OS based discussions on this thread are really
> quite moot.

Maybe I'm dense, or locally not getting it, but I just don't see what there is
to focus on. Sure, there
are different ways of messaging (synchronous or otherwise, smart or simple on
the sending/recieving
side, multiple/single recievers) but AFAIK, we implement (or would, anyway)
these by changing the
objects and the way they are implemented/represented.

So we're basically looking to change Squeak to a more general/malleable (but
reasonably efficient) way
of representing objects. How otherwise can you change the messaging part? What
am I missing?


> I would suggest that more progress could be made if the smart and talented
> Squeak list would think more about what the next step in metaprogramming
> should be -- how can we get great power, parsimony, AND security of meaning?

May I suggest a few small steps?
I don't think we have to make a decision on conversion to prototypes or to
circular meta-interpreters today.
Squeak already has a lot of capabilities in it that are just a little too hard
to use. I suggest we start carving away
the complexity we can by ordinary means. When we're done, either we'll have all
we want, or we'll be able to
say "we've pushed this as far as possible, to get <favorite meta-feature here>
in a simple way, we MUST
change to <radical new language model here>". Anyway, I'm sure a lot more of us
will have ideas as to what
they really want, maybe they'll even be new ideas.

What do I mean by "carving away complexity"?
Using most objects in Squeak is so simple it's intuitive. You can either guess
the selectors and what they'll need
or you anticipate them accurately enough that you can assume you know them. Not
so with the UI (morphic is
much better in this than MVC, IMO), and to the point, not so with classes and
their like.

Some things to think about:

Being able to send a message like -
aClass addMethod: 'arg1: anObject "this is a method" | tempVar | ^anObject'
rather than it requiring knowledge of the Compilers protocol, would do a lot for
the apparent flexibility of Squeak,
without requiring any changes at all.

If we wish to get some "feel" of what programming with prototypes might be like,
we can have the same method
in the object level create a subclass, become an instance of it, and then change
the subclass. This, along with refactoring
tools, might provide us with much of the flexibility of prototypes while
explicitly maintaining the structure. If this is
only a hindrance, we'll find out.

Brian Foote (and maybe others, I went through his papers) wrote about method
wrappers and class wrappers
allowing them to create various reflective effects. They and attendant support
in Class (Class>>wrapSelector:with:...)
could be added.

Blocks should be freer. They might have closure semantics, I think that 's what
people expect intuitively.
Come to think of it, it seems hard to me to explain why blocks and compiled
methods are separate things.
aClass execute: aBlock when: aSelector
seems like a very natural way to add behavior too, and would eliminate a concept
in the language. This would
require something like the class explicitly binding the block to itself after
the block's creation. But that's a relatively
deep change.

Change all those little things that stop people from kneading the system, and
then we'll find the lumps in the dough.

Does this sound anything like a plan to anyone else here?

Ok, I've rambled, now I'll shut up and listen to the smart, talented members and
experienced members of the list ...