slate comments

[Brian T. Rice]

I made sure to read up on all the papers you mentioned before responding.
Some of them I have seen in the past, but for the most part it was unknown
material. Thanks.

At 05:19 PM 3/15/00 -0300, Jecel Assumpcao Jr. wrote:
>Brian T. Rice wrote:
>> Also, objects are not represented within this syntax as lists of slots as
>> they are in traditional OO languages. Instead, an object is represented at
>> the language level by the expression which constructed it, starting from
>> the primitive object (for now there is only one, provisionally titled Root)
>> and taking all modifications to it as part of the object's expression.
>
>Interesting. This reminds me a little of the Lens language (hmmm... their
page
>no longer works - see http://progwww.vub.ac.be/Research/DefaultResearch.htm).
>It was a Scheme-like language where objects were defined as a sequence of
>object building expressions. Essentially, they tried to replace inheritance
>with "mixins".

Yes, Slate can support that kind of interpretation. However, I read the
Lens paper noting that they intentionally omitted the possibility of
cloning as in Self, which I found not only unnecessary but harmful. (See
below why I like cloning, other than for the reasons used in Self.)

As for using mixins in particular, I'm allowing the idea in order to allow
for the implementation of multiple inheritance and such above the usual
inheritance hierarchy, but the system won't use multiple inheritance
(delegation) very much, if at all. It does however provide a way to share
code in a coherent way.

>> Besides simply unifying state-update ideas with message-passing, it should
>> be known that Slate objects do not *contain* state as such. Their accessor
>> messages are the state essentially. Mutator functions update the accessor
>> functions. This reflects a sort of underlying source of complexity of
>> stateful languages vs purely functional ones reduced to functions muting
>> functions.
>
>Now this reminds me of the Dinnerbell language:
>
>ftp://ftp.ie.u-ryukyu.ac.jp/pub/papers/kono/tools-90-11.ps.gz
>
>If you have no seen it, it will certainly be worth your time reading this. I
>also saw an animation language in which objects had no state other than their
>message history but don't have a reference to it (some OOPSLA
proceedings). An
>interesting aspect of Dinnerbell was that methods were associated with a
>combination of message patterns, something like this:
>
>increment ; currentCount: x ==> currentCount: x+1
>
>This means that if this object has both an "increment" message *and* a
>"currentCount:" message pending in its queue, it will remove these two
messages
>and then send to itself another "currentCount:" message with a new value
as an
>argument. Note that the object can have any number of "currentCount:"
messages
>pending - programs must be written in such a way that this isn't a problem.

No, I hadn't seen this before. It's definitely interesting, but I've seen
the idea before in Maude's object-oriented modules where object behavior is
determined by equational rewrite rules. I'm of the opinion that this
complication placed on the programmer's shoulders to maintain the
message-queue structure is an unnecessary result of the syntax of the
message specification. However, Slate will simply be dealing with it at the
level of implementation, which I intend to provide openly to advanced
programmers. It definitely points out some interesting fine detail of the
message-history ontology of objects.

>> [...] I've also
>> barely touched on the Behavioral Meta-Object (BMO) system which intercepts
>> all message-sends. It's detailed to a small extent in the slate-semantics
>> page, but I'm still refining the idea. Basically, bmo's provide all sorts
>> of system services, like management of versions, mutability, and even
>> provide some re-factoring functionality. BMO's, by the way, derive from
>> some papers written in the early 90's about behavioral reflection in
>> prototype-based languages. They can be had from ResearchIndex.com, and I
>> can provide url's on request, although they don't elaborate on the uses of
>> BMO's at all.
>
>You seem to have adopted Moostrap's lookup+reply model for the meta-level.
>While I initially thought that Jeff McAffer's seven meta-object model for
CodA
>(http://web.yl.is.s.u-tokyo.ac.jp/~jeff/research/coda.html) was way too
>complex, as I struggled with a number of different issues I eventually
decided
>to adopt his design and abandon my own.

I haven't seriously considered the multiple meta-object idea since I was
trying to focus on simplicity for the user who delves into the meta-object
system in Slate, but I'm taking a look at the CodA documents that are still
available to see if the idea is workable. I'll let you know what I get from
them.

>One thing I didn't understand - you wrote "An entirely novel feature of Slate
>is support for immutable state slot-by-slot. This essentially amounts to
having
>the meta-object providing mutable state by default, and allowing each
>object to specify how its meta-object should update the object's slots."
It is
>great that you are handling this at the meta-level, but Self does allow
you to
>make any slot immutable simply by not defining a corresponding "assignment
>slot". They are called "constant slots", so I don't see how what you did in
>Slate is entirely new.

Okay, it seems that I fell short of using the right terminology, then. I'm
trying to encapsulate two different ideas into one term "mutability".
Essentially the issue in mutability is, "What happens to the object if you
try to mutate slot x?". I'm adding to that this, "What happens to the
*environment* if you try to mutate slot x?". This is where I believe I can
add a meaningful MOP that can be customized to a very extensive degree. For
instance, one might have a change to slot X create a new temporary context
that gets thrown away when the computation returns, perhaps even dependent
on the result of the code. Alternatively, one could have objects' accessors
create new objects in the same hierarchy with the new state without
bothering the old state. This could apply not just to objects but entire
namespaces that contain the objects whose state is muted, as well as
specified parts of the inheritance chain or the meta-object chain and its
hierarchy.

Notice that if you count the system-level slots of each object, like
'parent', 'meta', '..' (parent namespace), 'clone', and such, then you can
get some interesting protection features available to the programmer. In
particular, 'clone' meta-behavior turns out to be extremely powerful in
making the object structure fit a particular conceptual model.

Now that I consider it, it's possible that a multiple meta-object
interaction might help with factoring behavioral meta-object functionality,
but I'd need to find some existing working designs to adapt because
creating and working through such design ideas from scratch would take a
lot of effort.

So the difference is that I don't try to just "remove" the accessor method,
I keep it in the object and allow its meta-behavior to be dynamically
changed without affecting the original object. Of course, I'll provide
simple mechanisms that will allow one to migrate the desired part of the
meta-behavior of an object along with the object as a coherent unit. This
would allow meta-behavior migration to be customized to a fine degree to
support the various applications of the idea of meta-behavior.

I want to use the MOP to allow Slate to express naturally as many
programming styles as possible, even to the point of building the literal
system (mathematics, logic, text, graphics, etc) using the basic object
metaphor along with a customized set of meta-behavior. To this end, I'm
looking at structural reflection being built into the default MOP library,
either by multiple meta-objects or using simpler methods.

>Good luck,
>-- Jecel

Thanks,
~