[Squeak-e] Re: Comments on Lex's "Object as Capabilities in Squeak"

[Mark S. Miller]

At 11:48 PM 2/1/2003 Saturday, Mark S. Miller wrote:
>I think the real problem is that Squeak currently has a very rigid notion of 
>lexically nested levels of instantiation:
>
>Global
>Class/Factory
>Instance
>Method (activation frame)
>Block
>Block
>...

I don't know what I was thinking when I wrote that. Clearly, I was terribly 
confused. In Squeak, the Class/Factory level and the Global level are the 
same. I knew that, that's the origin of the problem we're wrestling with.

Also, "Method" is confused, about which more below.

I still make the same abstract recommendation, but the specific 
recommendation I made doesn't make any sense at all given the above mistake. 
Let's start again.

Let's model each level of instantiation in vaguely lambda terms. Clearly 
blocks are lambda-like, evaluating to block-closures which are closures. 
(Has Squeak fixed the old Smalltalk-80 bug, where block-closures weren't 
proper lexical closures? This bug must be fixed for Squeak-E.)

Method and Instance should be considered together as one level of 
instantiation. A message call and method dispatch can be described in lambda 
terms as

    An instance is a function of a message.
    A message call applies the instance-as-function to the message-as-argument
    The instance-function then does a switch or something on the message selector.
    A method is just a case of that switch.

Now, things start to get a bit messy. An instance's instance variables are 
declared by the class. A call on the class-as-factory instantiates the 
instance, but does not initialize the instance variables. Instead, by 
convention, an initialization method does so, which, as Lex points out, will 
require all Squeak-E programmers to write extra code to suppress redundant 
initialization, unless this convention is changed. I like the lambda 
solution to this problem, but there are others that are less disruptive to 
Squeak code, such as Java constructors. I leave it to y'all to judge which 
is more disruptive to Squeak taste.

The next level of state -- class variables, pools variables, classes 
themselves, metaclasses, class instance variable, global variables -- are 
all at the global level of instantiation -- as each such variable has one 
binding per global scope. Most of these are mutable, or enable mutable state 
to be reached. Many of these also convey authority. In Squeak-E, the only 
objects that can be at the global level of instantiation are transitively 
read-only ones (transitively immutable is preferred) that convey no authority.

What if the only classes that appeared directly at the global level of 
instantiation were those that lived comfortably in those conditions? Let's 
call these top-level classes.

What if all other class definitions appear in some method, where the 
in-scope variables at that place in the method (locals, parameters, instance 
variable, on out) are also in scope to the nested class definition, in 
proper lexical scoping fashion? Even Java does this correctly.

Then we could deal with "World" by having an outer class with "World" as a 
factory parameter, and it would instantiate inner class factories with World 
in scope. When these factories were then called to make instances, these 
would also have World in scope according to their instantiating context, not 
their calling context.

The above tale leaves Squeak-E more like Squeak but harder to implement in 
Squeak. Alternatively, if Squeak-E only has lexically nested instances and 
factories but not classes, then these can easily be implemented by expansion 
to top-level Squeak classes, where all the closed-over variables of the 
Squeak-E factory are turned into instance variables declared by a 
corresponding factory-class. Or, you could go the E way and have no 
primitive notion of a factory -- just make it a pattern. Then, a nested 
browser would correspond to an instance definition, and be an expression 
that evaluates directly to the instance. Less like Squeak, but easy to 
implement.


When I wrote this message, I did not intend it to lead to the conclusion "Do 
it the E way". However, I did things this way for certain reasons, and this 
discussion is helping me rediscover them. But having done it this way, these 
techniques have formed grooves in my mind it's all too easy to slip back 
into. I many very well be missing something.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM