slate comments

[Jecel Assumpcao Jr.]

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".

> 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.

> [...] 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.

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.

Good luck,
-- Jecel