Slate implementation in progress

[Brian Rice]

At 12:36 PM +0100 3/20/02, Joerg F. Wittenberger wrote:
>Hello Brian,
>
>Thanks for your reply.  I read a few things about Slate now.  Again I
>found heavy simillarities with Askemos internals, but that's something
>I observe whenever I find a minute to look closer towards TUNES.

I'm going to re-iterate my broad disclaimer which I gave to you in my 
last reply: The documents on http://slate.tunes.org were made in the 
middle of the brainstorming process and don't reflect the current 
ideas in Slate. However, I'll correct and explain what I can to keep 
misunderstandings to a minimum.

>I've got a few more questions:
>
>>  Built-in support for behavioral reflection:
>>
>>         In Slate, every object looks to some behavioral meta-object
>
>Please forgive, I'm very confused with the use of "meta" all over the
>place in computer science, which is too often simply wrong application
>of a term.  (not saying that it's here, I'm just careful to avoid
>missunderstanding.)
>
>What does "looks to" mean here?

It means that the behavioral aspects of the object, it's protocol, 
are both represented and implemented by it's behavioral meta-object. 
In truth, the way we worked it out is that every object has its own 
separate aspect of behavioral reflection, which often shared 
component parts between many other objects, but existed to reflect 
its particular objects' behavior. Now, meta-behavior in the sense I'm 
using is all of the effects that are incurred by performing a lookup 
in the object. So the behavioral meta-object *implements* a 'lookup' 
method, as well as some default rewrite methods that happen when The 
continuation returns, defined explicitly in the MO (meta-object) as 
an 'apply' method or something similar. The idea was to reduce the 
fundamental protocol to a minimum to allow us to implement them in 
any way we desired. There are some auxiliary methods to these, like 
enumerating slots and such, but these don't increase the fundamental 
surface-area of interaction.

>  >        (or resides in some meta-space) to implement its protocol
>>         semantics, particularly with regards to its accessors. The
>>         behavioral meta-object encapsulates much of the semantics of
>>         the language, and behavioral meta-objects are available for
>>         all of the same programming tools as are objects. However, in
>>         order to avoid meta-circular regression, there will be
>>         implemented a behavioral meta-object which describes its own
>>         meta-behavior. This system allows for extension by simple
>
>Are you already at the point that the meta object, which describes
>it's own behavior?  I'd be very interested in details.

The primitive behavioral MO? Actually in the references section 
(http://slate.tunes.org/doc/references.html) of the website, I 
mention a couple of old papers on reflection which address this, 
although we have been modifying the idea quite a bit.

>All the security features of Askemos derive from that single fact
>and simply doing a small mistake (which ended up to be a config
>variable) would allow to execute anything - complete anarchy.
>
>>         cloning. The current policy is that behavioral meta-objects
>>         are immutable by default, since their changes are more
>>         significant. Also, we intend to address the idea of
>
>Ah, that's exactly the small mistake.  If the behavioral object
>(behavioral document or action-document in Askemos) was mutable, that
>anarchy follow.  Maybe Slate doesn't need it?

Slate actually happens to use it's meta-objects to define mutability, 
or more accurately to what happens to the object on a particular 
lookup. We may factor this out into a separate meta-object to make 
the interface more clear. Here's a basic notion we've been building 
on: whenever a lookup is made, the object has the option of not being 
the one the side-effect occurs on, so it can have itself cloned into 
a new generic symbol in its context with the lookup already in 
progress. The context may, in turn, balk even at the addition of the 
generic symbol slot, and force a further copy of itself, which places 
the burden on *its* context, and so there's a recursion there.

This is a simple approach that seems to be mostly workable, in that 
wide-spread simulation of changes can be made and returned from (with 
a result) without affecting parts of the system that don't want it.

Unfortunately we also want to deal with the TUNES HLL constraint that 
changes can be broadcast to a controllable range of the world, so we 
will eventually have to elaborate upon this.

>  > Message-Sends
>>
>>  We'll start with the basic protocol: method execution = lookup +
>>  apply. The semantics of the message send will be the following:
>>
>>  (object (selector arg1 arg2 arg3)) =>
>
>I can't make head or tail of that.  What is 'selector'?  The 'name' of
>the message/function?

Yes, pretty much. It gets looked up in the object, and the following 
words get looked up successively. What's not obvious is that those 
parentheses can be dropped without affecting the lookup process: 
Slate syntax is at its heart concatenative, and code-quotations are 
lists, just as in Joy. The meaning of the parentheses has to do with 
how side-effects and results/returns are handled, and allow for some 
additional modifiers to be placed into the code as well. But this 
explanation needs to wait until I flesh it out in code.

>  > ((object meta)
>
>(object meta)  ==> ???
>
>What is 'meta' here?

The meta-behavioral aspect of the object, a.k.a. the behavioral MO.

>  >  (applyTo_withArgs ((object meta) lookup_In selector object)
>>            object argList))
>>
>>  Both 'lookup' and 'apply' will be implemented in the meta-object for
>>  the reciever object. An alternative would be to allow the reciever
>>  object's meta-object to override the meta-object where the method
>>  definition was located, but this is an untested idea.
>
>Could you expand a little, please?

I've explained some of this above, but elaborating on what's 
happening here can wait until I get the code running, so I can 
explain the behavior of something that you can actually observe.

>Regards, thanks
>
>/Jerry
>
>PS: I cc'd the askemos mailing list.
>
>--
>The worst of harm may often result from the best of intentions.

Indeed.

~

--