Slate

[iepos@tunes.org]

> >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?
> 
> [explanation]

Okay... that makes sense...

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

The simple syntax you're talking about is the "(object message)"
syntax, right? It is interesting... this way of doing things is
somewhat similar to the way I was going to do it with my purely
applicative system... it was based on a binary construct, from
which (along with primitive words) all expressions were built ,
although the binary construct was called "function application"
instead of "message send"... of course, you system seems different
in many other ways, though...

> >> 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?)

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)

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

By the way, is this the way you would have done it before? :

  (foo ((modify (at : 2)) (to : 5)))

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

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

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

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

- "iepos" (Brent Kerby)