Slate

[iepos@tunes.org]

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

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

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

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

> [...]

all interesting...
hopefully something will come of your Slate...

- "iepos" (Brent Kerby)