A first look - some comments

[Brian T Rice]

On Fri, 5 Sep 2003, Peter Hugosson-Miller wrote:

> Hi,
>
> I am new on the list, just joined today, after spending the morning
> browsing the Slate site. I live in Stockholm, Sweden, and am a
> Smalltalker full time since mid 1995 (though in today's jobb climate
> that may have to change RSN).

Welcome! Unfortunately, I am on the RSN list already. :/

> I must say I am very impressed with Slate, and like what I see of it so
> far. I can see how polymorphic multiple dispatch could be useful, as it
> could remove the need for much double-dispatching that only exists
> because you can't overload method names (in Smalltalk).

Yes, and thanks. Most Smalltalkers actually claim it isn't needed often
enough, but that often turns out to be that they don't double-dispatch in
their library desgins as often as they should simply because it takes more
effort.

> In order to be sure that I followed the syntax and language semantics, I
> took the demo life program from the CVS repository and translated it to
> Smalltalk. I would recommend this exercise to anyone who knows Smalltalk
> and is trying to get their head around Slate. It is very simple to do,
> and just translating really hammers home the prototype-base philosophy,
> and the need to think about who the receiver is for any given message. A
> little side quest for you too: there is a method in life.slate that is
> defined but never used, can you find it?

Well, I wrote it, so I probably shouldn't just give away the answer (which
I did just verify, to be sure). ;)

As far as translation, yes, this does seem to be a good way to learn. At
some point, we'll need some good tutorials, and comparing Slate to
Smalltalk code might highlight the advantages.

> I do have one problem that I still don't really understand. On the
> Syntax page http://slate.tunes.org/syntax.html about half way down in
> the "Expression Sequences" section it says that "...there are no
> cascaded message-sends since there is no preferred "receiver"
> argument.". OK, you decided not to have cascaded message sends, but I
> don't follow the reasoning as stated. For example from life.slate:

(Omitted very common example of where cascades would make Slate code more
concise).

> In this case, at least, the receiver is (to me) quite clear - LifeGame
> is sent the messages #addSlot: and #addSlot:valued: with in the first
> case a Symbol argument, and in the second a Symbol and an Array as
> arguments. I must not be understanding something about the multiple
> dispatch, because I can't see anything in the above preventing message
> cascades from being used, like in the Smalltalk version. I think I would
> miss them too, as they are so useful in init methods.

Well, the truth is that /all/ arguments in a message-send in Slate are the
receivers. They're being asked to cooperate in a behavior, so to speak.
The PMD paper (http://tunes.org/~eihrul/pmd.pdf) explains the basic
metaphor anyway (although the lookup description is outdated). So,
although we also do prefer cascades for clarity, it seemed at odds with
the basic language metaphor to not treat the left-most argument specially.
However, arguments to the left do receive greater precedence, so this
reasoning isn't ironclad.

I should mention that ";" has been re-used as a binary operator, for
concatenation and stream-writing, and works well that way, so it's not
trivial to go back.

Anyway, the general work-around is to allocate a local variable with a
short name and send to that, which you'll see in most methods where you
would ordinarily find cascades.

Also, the example you gave of setting up Namespaces is not too hard to
elide just using the Inspector tool:

lobby addSlot: #LifeGame valued: Cloneable derive.
LifeGame addSlot: #screen.
LifeGame addSlot: #height.
LifeGame addSlot: #width.
LifeGame addSlot: #cells valued: {}. "Array of size H * W."
LifeGame addSlot: #newCells valued: {}. "Array of size H * W."
LifeGame addSlot: #randomStream.

becomes:

lobby addSlot: #LifeGame valued: Cloneable derive.
inspect: LifeGame.
it addSlot: #screen.
it addSlot: #height.
it addSlot: #width.
it addSlot: #cells valued: {}. "Array of size H * W."
it addSlot: #newCells valued: {}. "Array of size H * W."
it addSlot: #randomStream.
close.

Of course, this adds some context-dependency and isn't quite as natural as
a cascade, but cascades themselves add a similar complexity to Smalltalk
grammar (not much, but it exists).

(Hm, I just noticed that:

lobby addSlot: #LifeGame valued: Cloneable derive.

should be:

lobby addPrototype: #LifeGame derivedFrom: {Cloneable}.

to take advantage of a relatively recent API shift.)

Also, a lot of this systems-setup code with adding and setting slots and
such is supposed to be done visually at some point (when I get the system
support up to the needed levels). Unfortunately, getting to that level
obviously takes a lot of time and work, but that's what is in mind.

> So, just my 2 cents! I'm not complaining, rather asking to be
> enlightened. Thanks in advance.

Sure.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/