A first look - some comments

[Brian T Rice]

On Tue, 9 Sep 2003, Peter Hugosson-Miller wrote:
> Brian T Rice wrote:
> > On Fri, 5 Sep 2003, Peter Hugosson-Miller wrote:

> <Grin!> And while I'm on the subject, in order to make the program work
> correctly in Smalltalk, I had to change the #new method, so that cells
> and newCells were different objects, by setting newCells to be a copy of
> cells (which I guess,  in Slate, might be): "newG newCells: newG cells
> clone". Without this change I got a different behaviour from the normal
> Life Game, which never settled down into the familiar patterns of the
> original. Was this a bug in your code, or is there a subtle difference
> in the handling of arrays that I ought to know about?

It was a bug; I've added the fix now, although now that I look more
closely at the output, there's probably another bug dealing with checking
the new array vs. the old one.

> >> 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.
>
> OK, I read the paper, and I think I get the basic idea. At each method
> invocation you start with a clean slate, put all the concerned variables
> on it, together with the selector, then work out exactly which method to
> call based on which most closely matches the types of the variables in
> the given positions. But you are still probably going to use a stack as
> that clean slate, and you have to push them in some order, which would
> most logically be the "receiver", followed by the "arguments", so you
> can take account of precedence. So if you wanted to have message
> cascading this could be organized by the compiler first pushing an extra
> copy of the "receiver", doing the PMD-related stuff, then popping and
> discarding the result. This would not affect the PMD mechanism, as that
> all happens at runtime.

Right, that's mostly how it could happen, but you would also have to make
the bytecode compiler pop the messageSend's result implicitly as well. It
would probably pay off to allocate one of the few remaining bytecodes for
sendMessageForCascade, which leaves the first argument on the stack and
does not push the result, assuming we were to adopt cascaded sends. This
is not a priority to me, but I'm not against it.

> > 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.
>
> I would have no problem with using a different character as the cascade
> indicator, if it meant I could write more concise code. It's a different
> language after all, even if the syntax looks a bit like Smalltalk. I
> personally don't like the work-arounds you suggested, but it just might
> be that I have been cleaning up other peoples code for too long, and
> have the typical Smalltalk idioms "in my blood" :-). I guess one could
> get used to the Slate way too, given practise.

Well, the suggested workaround was just what has occurred to me so far. It
could take a much different form as necessary. If something does occur to
you which seems reasonable, make the suggestion, of course.

> > 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.
>
> For browsers and such, I guess one could take a look at Squeak for
> inspiration. I believe it to be the Smalltalk dialect that has been
> ported to the most platforms, and if Slate is to propagate it needs to
> be available for as many people as possible, as early as possible. Doing
> all the widgets in Slate would speed up this process, as you wouldn't
> have to write any platform-specific code once you had the basic
> bit-blast working. Native widgets would then emerge naturally from the
> community as the number of Slate enthusiasts reached the critical mass.
> At least, this is what seems to be happening in Squeak.

Squeak was one of the primary inspirations (motivators?) for creating
Slate. I have used it for years and constantly consult it. Anyway,

> Sorry for this long and not very helpful post, but Slate interests me,
> and I hope that it has a future. I think it's time for to try and get
> Slate running so that I know a bit more what I'm talking about...

Great. :)

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