slate comments

[Brian T. Rice]

At 08:47 PM 3/21/00 -0300, Jecel Assumpcao Jr. wrote:
>Brian T. Rice wrote:
>> >[Dinnerbell language]
>> 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.
>
>Yes, I mentioned it as a source for interesting ideas, not as an example to
>follow. Solving these problems (concurrent state management) by making things
>so low level that the programmer has to figure the nasty details out by
himself
>is a good way to solve toy problems, but not to write real systems.
>
>> 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.
>
>The key point in CodA was decoupling message sending from message
receiving so
>that you could implement several different models of parallel and remote
>execution.

Okay, this did interest me as an issue, but I thought it would be a bit
difficult to work in without some confusion related to the semantics of
each part of the message-send (send and receive). To me, this dichotomy of
the message-send mirrors the lookup+apply idea of moostrap. How is it
different in its most appropriate usage? Does it make the lookup+apply
model obsolete? Can they co-exist peacefully? Sorry to be so inquisitive,
but I (and I suspect most other people) haven't explored these ideas
adequately. It just seems that it would be confusing to the MOP user to
place his desired modifications in such a framework as send+receive unless
it had to do specifically with distribution or timing. It would seem
especially so if the lookup+apply model were mixed with it.

It's obvious, for instance, that intercepting sends and receives allows a
very nice management of distributed schemes where message-send times are
significant. However, I'm not sure that another idea I'm considering about
distribution would not work just as well to accomplish this reification;
it's termed demand-driven concurrency and involves using function-calls as
rendezvous points. I had intended to use namespaces to model domains and
intercept different parts of my existing mutator structure, involving both
accessing the source namespace and then delivering the value to other
objects that are waiting for the value. This is possible as I see it
because of a lazy evaluation strategy by the evaluator, although I haven't
worked out all the issues with this. Would this address the issues that the
send+receive model seems to solve, or is that model simpler in some way
that I don't understand?

>> >[Self has immutable slots]
>> 
>> 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.
>
>Right, this allows you to have total control over the semantics of object
state
>changes. I am having to deal with this in my distributed persistent object
>store system (at a much larger grain, of course, and with much less
flexibility
>than you have).
>
>> 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.
>
>What is the difference between "parent" and ".."?

Well, 'parent' deals with the delegation chain(s) of Self, which in Slate
is a single chain due to the fact that objects are types of functional
expressions instead of slot lists (a minor distinction). What you
ordinarily will get in Slate would be the same expression sans the last
object modification down the inheritance hierarchy (not necessarily object
history as the user sees it). In order to get back in the history,
structural reflection is needed.

The '..' slot deals strictly with containership, and should have very clear
semantics. It simply returns the namespace (object) enclosing the current
one. Note that ordinarily, accessing higher-level namespaces in Slate will
be done by mutator slots (which are slots of the accessor objects), where
the mutator slots automatically access a specific namespace, much as the
Lobby and Traits are available from anywhere in Self.

>> 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.
>
>The idea is that you can "snap together" a few dozen meta-objects in hundreds
>of different ways, instead of writing hundreds of different meta-objects by
>hand. With a good framework, like the Guaranį system mentioned in a parallel
>thread, you can even mostly automate this configuration process.

Yes, this is what impressed me so much about the idea, especially if I can
manage to implement it with Composer meta-objects simply containing the
meta-objects (their clones) to which they delegate.

>> 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.
>
>Yes, it is possible to do better than Self's immutable slots. I was just
>mentioning the fact that they existed. In fact, in previous versions of Self
>which had slot privacy and lookup-tie-breaker-rules they had much richer (but
>confusing) semantics.

I have heard of this, but I never considered it a set of features worth
carrying over "as is" to Slate.

>My own system is a multiuser one, so objects might be immutable due to the
fact
>that the logged in user doesn't have write permission for them. Both the
>compiler and the scheduler can do optimizations based on this.

Yes, I have this in mind as well with my mutability system in Slate. I had
intended to use the system of having namespaces represent domains in order
to encapsulate this protection mechanism, although I haven't drawn up the
details yet.

> > 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.
>
>Of course you have to have structural reflection of some sort - otherwise you
>can't write the Slate development system in Slate!

Oh yes, this reminds me to bring up an issue for your comments. We are
currently working out various options for structural reflection in Slate.
Of course we looked into Self's library of mirror primitives, and it seems
a good idea, although it's based on the Self VM set of primitives
specifically. So we're looking for a system that's a bit more flexible.
We've found two projects so far that have good ideas.

The first is the Shape project at
http://linus.socs.uts.edu.au/~shape/shape.html . It's another functional
language idea using category theory to allow a formal separation of
data-container shape from its contents. There's a particular paper
available that attempts to address an object-oriented application of this
very interesting idea, but it's only a primitive stab in that direction.

The second idea is a very experimental extension of the ideas of rewrite
systems that I'm working with to provide much the same way that macros do.
I'll present my ideas when I have a clear notion of what all this will
involve.

Incidentally, what do you recommend for a quoting mechanism?

>-- Jecel
Thanks,
~