Alan Kay:

>       On this list, I've mentioned several times that variables and
> instances should be objectified. This has been done in several other
> systems to provide much better leverage on a number of important
> problems.

Could you say more on those systems? What does it mean to objectify
(reify?) a variable?  In a sense it is already reified if we understand
it as an *association* name-value. Pragmatically it is very different
from a "typical object", and its status depends very strongly on the
programming language. A logical variable in Prolog which can exist as
'uninstantiated' is a meaningful example. A variable in FORTH is an
object in the sense that the user has to demand explicitly (send a message
if you wish) that it be dereferenced. But this is rather cumbersome...
So, please, what do you really want, could you be more specific?

> Messages and message sending could be more objectified. This
> would allow a much more flexible approach to trying delegation
> schemes, finding alternatives to inheritance, etc.

Trivially messages are objects, but it is difficult to do something
with them, apart from sending them... In what sense the message 
*sending* should be objectified?

>From time to time I read here and there (and I say it myself, albeit
without much conviction...) that OO subsumes - in a sense - the
functional programming. A closure is an object which 'can be called',
or can be 'applied' to other objects (and - of course - it is practically
done in C++ or Python by ovrloading the () methods). But: what about
iteration as tail recursion? Can it be formulated seriously in a OO
framework? How can we understand such a phrase "the *execution* of
a program should be objectified"?


Finding alternatives to inheritance is something which bothers me for
several years... What I find particularly refreshing is the decoupling
between classes and types, as formulated through the 'type class' systems
of such functional languages as Haskell or Clean. (BTW. the classes
therein are much more close to mathematical categories than classes in
any other OO system). We see now the appearance of "polytypic programs",
the 'generic Haskell' project etc. - all that enhances coinsiderably
the polymorphism, and the reuse of common programming patterns. Perhaps
the Smalltalking people could have a look on all that? 

It is obvious that in many programming domains we need much more than
classical inheritance. The computer algebra (in a modern framework - not
as a mangling of symbolic, syntactic terms, but as processing of complex
mathematical structures) issues is a typical example. We need 
*subsumptions* ((e.g. while we can define objects belonging to well known
mathematical hierarchies: AdditiveGroups, Rings, Fields, VectorSpaces
etc., it is not so easy to implement gracefully such properties as that
all additive groups are modules over integers (because if you can add
x+x, you have "for free" 2*x...), that a ring of congruences becomes
automatically a field when the modulus is a prime number, etc.)) All
this requires (IMHO!) that the Meta level be treated very, very seriously...


>      Another method objectification would be to have many polymorphic
> methods be instances of a class that guards the meaning of the
> polymorphism. This is part of having a model for both variables and
> "slots", etc.

Once more, in the functional programming realm it is a major issue. But
there, classes and types are animals of different races. How to choose the
best from both worlds? 


Thank you.

Jerzy Karczmarczuk
Caen, France