Slate

[Brian T. Rice]

At 07:46 AM 3/14/00 -0800, iepos@tunes.org wrote:
>> 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.
>
>Interesting... one question... message-sends do have returns, correct?
>If you wrote "(x (y z))" this would mean, "send message 'z' to object 'y',
>and send the resulting message to object 'x'", right?

>But, I don't think I really understand your system, so maybe this 
>would not work ...

Yes, but there can be many subtleties to this process, mostly determined by
the use of the behavioral meta-objects. For instance, there is a way to
have the returned object be intensionally defined as the result of this
message send in a way that duplicates the ideas of using combinators. Of
course, the usual object-oriented idea of obtaining an instance of a value,
which is cloned to get duplicated is also available. These meta-behaviors I
mention are not merely features, but instead represent examples of how to
customize the general capacities of behavioral meta-objects. I'm putting
together a summary on how behavioral meta-objects can be used, which I will
use to explain how Slate can fill nearly every HLL Requirement fairly
easily, although it's a totally unorthodox approach. I even wind up
breaking the normal programming language math, logic, and text systems in
favor of something more flexible.

And I should mention that all this will be done without leaving the syntax
and conceptual model I have just mentioned. The versatility comes from
meta-behavior and its customization.

>> This requires a special symbol ":" as of right now, but I am looking for a
>> good clean way to avoid the notational kludge.
>
>Hmm... maybe this is one way... fill slots by sending messages to them;
>for instance, a slot "foo" could be filled with "x" by "(foo (fill x)"...
>("fill" would be an object which takes a thing and returns a message
>to fill with that thing).

Yes, that seems like the obvious fix, until you realize that argument
bindings in Slate are accomplished by message-passing and that mutator
messages must also have inputs bound to slots, so you wind up with:

(myObject (setVar1 (setFoo (setFoo (setFoo ...

What's going on in the above example is that you're trying to set Var1 in
myObject. So you naturally send myObject the setVar1 mutator message, but
you have to give it an input. So supposing the setVar1's input slot is Foo,
we send a setFoo message which also has to get *it's* slot bound, resulting
in this absurdly endless recursion.

There are several alternatives. The one I already mentioned amounts to this:

(myObject (setVar1 : x))

In this example, we have a symbol ":" which could be regarded as a message
or a keyword. Either way it makes mutator messages special, since you
either have all mutators inherit ":" from some common ancestor, or you have
":" implicitly collapse that infinite recursion implicitly. However, this
":" symbol could only be used in situations where the object only has one
slot to set, so multiple inputs to a message must be factored explicitly
into message-binds to each input slot. I'm not satisfied with this
approach, and I think it signals that a different conceptual approach would
help. On the other hand, one could say that it represents a fundamental
problem with some aspect of this notion of function.

Here's another take on the situation. The use of a mutator (or by extension
any message that takes an argument) requires the ability to get the input
from any place within the large-scale system (system environment, if you
prefer). In most languages, namespaces divide up the system in terms of
accessibility of value, and this is usually an after-thought to the
language design. In Slate, the namespace aspect of the environment develops
straight from first-class Slate objects' properties. (The same applies to
Self, actually, though they handle it in a less expressive way). This
actually breaks the "(object message)" syntax concept, since you very often
escape a namespace to get a return value. Most language designers just
sweep this detail under the carpet; apparently uniformity isn't the top of
their priorities. There's no escaping the need to do this if you have a
namespace hierarchy (actually I recall that this is mentioned in my Arrow
paper). Right now, my alternative involves a simple file system path
metaphor (a "/" symbol), which is mentioned at the bottom of the Semantics
page for Slate. This is mostly a stop-gap, but essentially it just isolates
this problem of getting values around namespaces to cloning (anonymously to
avoid identifier bloat).

I have other solutions that I'm working out right now to eliminate both ":"
and "/" but I need a little time to develop them before explaining them.
For now, the language works fine, I think, with only four symbols (counting
parentheses). It at least demonstrates some interesting concepts.

Another thing I should mention is that there's an alternative syntax I'm
considering to make the language simpler to read, replacing the strict
"(object message)" with "(object message message ...)" which helps when
you're binding arguments to selectors, but this requires changing the
syntactic function of the parentheses to avoid confusion. It's mentioned at
the bottom of the Semantics page, but it's very experimental, and I've
found it unsatisfactory since many message types and meta-behaviors cause
confusing behavior, so it will probably be dropped. Note that I intend for
the primary interface to Slate to be graphical or intensional, so that a
lot of syntactic issues will be different from what the textual syntax
suggests.

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

Luca Cardelli uses this notion in his Object Calculus papers, but it's not
a very well developed idea there in terms of its application to large-scale
systems.

>> [...]
>
>all interesting...
>hopefully something will come of your Slate...

I hope no one takes this the wrong way, but I'm implementing whatever
becomes of Slate with or without Tunes' help. However, I would think it a
crime for as many people as are subscribed to the Tunes mailing list to
listen to these ideas and simply do nothing.

>- "iepos" (Brent Kerby)

~