Slate

[Brian T. Rice]

>> >> 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.
>
>Okay... I think I see... the normal way to send a complex message
>to an object is to start with a basic message and then modify some
>of its slots (the parameters)... and then send the modified basic message
>to the object... (right?)

Yes, but keep in mind that the "(object message)" syntax basically gets
internally re-written by the evaluator into "((object (messageObject
result)) result)". The "result" is an accessor message that provides the
execution tug on the code within the objects. All messages are just objects
in slots. The enclosing object has names that it can invoke these objects
"result" messages.

>There is an alternative way of doing this which might solve your
>problem: use a technique like currying (instead of slot-filling) 
>to pass multiple parameters. To illustrate, suppose you had a list
>of numbers named "foo" and you wanted to modify element number 2
>in it to be "5"; then, in the currying style you might do something
>like this:
>
>  (((foo modify) 2) 5)

Hmm.

>In this case, when you give "modify" to "foo", it gives you back a
>an object for modifying "foo"; then, you send this modifying object
>the first parameter "2", and it gives back another object which takes
>the final parameter; then, you send the final parameter "5" to it,
>and then the modification will be complete (whether this means the
>list will change in its place, or a new modified list will be
>returned I don't know; either way you do it, the currying technique
>will work, I think).

Well ultimately it comes down to "What will the object-message metaphor
support?". When you consider that I'm making my objects and messages
namespace-objects down to the bottom, you'll see that passing arguments
amounts to having every possible object available within the slot's
namespace, which isn't too friendly an idea to the average object
programmer. Right now I hide this by using the ":" special syntax form. I
could make it more explicitly available by allowing circularity within the
namespace structure, which I am certainly not above doing. It's just that
it requires more thought to go into the process. I *could* have a common
traits object for mutator methods themselves, with the ":" slot within it
accessing the root namespace or some such idea. A programmer could provide
type-checking simply by creating a special version of this that only may
access a sub-namespace of this one. An example that comes to mind is the
integers, which by the way will be (immutable, of course) objects which are
slots in the Integers namespace. The same goes for all of the other literal
types.

>By the way, is this the way you would have done it before? :
>
>  (foo ((modify (at : 2)) (to : 5)))

That's fairly odd... This is how I would have done it:

(foo (2 : 5))

This assumes you name the slot '2', of course, or provide a protocol that
addresses the slots with natural number slots. I don't think of numbers as
special identifiers or even as representing single ideas, so perhaps I'm a
bit unorthodox that way.

>> [other options]
>>
>> 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 [...]
>
>If you adopt currying as the normal way of passing around multiple
>parameters, then you may want to allow "(object message message message ...)"
>to be sugar for "(((object message) message) message)"... that would
>fairly harmless...

Yes that was the intention. Perhaps I'll do that and remove it later if
people complain.

>Another, simpler, alternative is to use something like "@" as a binary
>prefix operator... The example with "foo" above could be written
>
>  @ @ @ foo modify 2 5
>
>This has the slight advantage that you only need one symbol instead
>of two; it would probably also be easier for the system to parse
>and write. Here is another example ...
>
>  @ @ f x @ g x
>
>Which could be written in the ordinary syntax as
>
>  ((f x) (g x))

That's interesting. However, @ intuitively looks like it should be an
object, so it's a little confusing to me. Perhaps this level of simplicity
is unnecessary since the syntax is already equivalent to an abstract syntax
tree. But it helps raise the idea of reifying the objects that provide
syntax structure, which is good for reflection.

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

>Heh heh ... well, your Slate looks promising, and I'm willing to help
>where I can with it, but I'm not sure that it's necessarily superior
>to the other approaches some TUNES people are working on (for instance,
>the Joy-style stack-based systems Billy and I are considering also
>show great promise) ...

I don't doubt it, but I intend to prove that I can make Slate into a
species of language that doesn't exist yet, because it was right under
peoples' noses. This'll take time to work out, so please be patient and
don't take the current Slate working documents to be literally the intended
result.

>> >- "iepos" (Brent Kerby)
>> ~
>- "iepos" (Brent Kerby)
~