No subject

[Brian T. Rice]

Hello all,

I've been quiet of the mailing list for quite some time, keeping to myself
and learning a lot of things. As you all know, I've been playing around
with a lot of ideas to construct the Slate language, which I believe is a
step towards Arrow or Tunes, depending on your viewpoint. At any rate, I
have a lot of the ideas worked out, and I have a lot of knowledge gained in
working through the language's ideas. However, a lot is still missing
and/or not stable to the specification, so I am very open to suggestions.

Specifically, I'd like to put it to the group to decide whether or not
Slate could fill the requirements of the Tunes HLL Sub-Project, and to
point out where or how it could change to do so. Keep in mind that Slate
has some odd concepts in it. It's a very unorthodox approach to unifying
purely functional ideas with the object-based ideas of Self and its few
relatives in research.

For reference, the contents of http://www.tunes.org/~water/slate-home.html
and in particular that of slate-semantics.html provide the documentation
for Slate right now, although much remains to be specified.

So, to start, I'm listing item by item the categories in Fare's famous
"Requirements for the TUNES HLL" at
http://www.tunes.org/HLL/requirements.html. I'll address how I plan to
develop Slate in order to fulfill them. At the very least, this should
spawn discussion over the fitness of the specifications of the HLL, which
is why it's been forwarded to the mailing list to address that.

__Founding Principles:__

_Genericity_

Well, this seems like an abstract meta-category, so I'm not sure how to
answer it fully. However, I can say that Slate has a very simple syntax
which is basically solely the "(object message)" sexp syntax within CLOS.
Notice that I have not mentioned arguments within that expression, as
argument binding is provided by messages to fill the slots of the message.
This requires a special symbol ":" as of right now, but I am looking for a
good clean way to avoid the notational kludge.

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.

Naturally, this is cumbersome, so Slate will provide a simplified
expression equivalent to that one which is trivially equivalent to the list
idea. It will mostly consist of "add-slot" primitive sends as well as state
mutator-like functions (state is an illusion in Slate). Of course, the
implementation will be little different from normal OO, in that method
dictionaries will be cached for lookups instead of these expressions being
evaluated.

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.

_Precision_

This as best as I can address, deals with both syntactic overhead for
expression of objects, which I addressed to an extent above, as well as the
overhead of the conceptual content of an object required to perform the
desired function. As for this latter aspect, I believe most of my arguments
could be contained by the ideas of the Self papers, particularly "Self: The
Power of Simplicity". Further simplicity can be had by various methods,
including the factorization of Slate's behavioral meta-objects from its
objects. Another possibility is the provision of new roots of object
behavior other than the default, although I have not sufficiently looked
into this.

_Uniformity_

In Slate, of course, all abstractions are objects. However, I should
mention that methods are no less general than objects. Both provide an
inner lexical scope, so that blocks as such are not needed. Also, both
messages and objects are functional entities. They contain slots which
through meta-behavioral guarding can act as inner variables, input
variables, or intermediate expressions.

The description of a method is like this: it contains input-variable-like
slots which clone the object on being muted. Other slots are expressions
that take these slots and compute other intermediate values in the
computation. Finally, the expression in the special 'result' slot is the
output of the method. All objects in Slate have this 'result' slot, and it
can serve a variety of purposes.

There is even another aspect to uniformity in Slate. Objects as lexical
scopes act as the namespace mechanism for Slate. Modules in this case
simply happen to be objects nested into the system-wide namespace or one of
its descendents whose slots are the relevant objects to the module. There
are ways to extend this to easily handle all sorts of extra behavior, but
that's beyond the scope of this description.

_Consistency_

Slate's model of state as a group of slots that are functional expressions
means that changes get propagated using the usual functional techniques.

_Orthogonality_

Well, I have to admit that I don't have a specific answer to this, although
it doesn't seem a very difficult thing to obtain from a clean start.
Perhaps comparing Slate to Scheme would help in this respect. Comments
welcome.

__Basic Principles__

(To Be Continued...)

Actually, this is already long enough as it is, and I'm sure it will prompt
a lot of questions. Please look at the Slate documentation a bit before you
reply, since all of this is very fresh. Also, for those of you not
familiar, the Self system provides a lot of documentation that explains
concepts that I use in Slate, like prototype-based inheritance, dynamic
systems, direct-manipulation object interface systems, and such. 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.

Obviously I've kept this under wraps for too long, since I've already
worked out a lot of the ideas to a great extent, but then a lot of it still
needs refining. I'm also well aware that Slate is not part of the Tunes
.plan, since it's definitely different from Scheme, so it's up to you to
make sense of the two.

Well, enjoy!

~