[squeak-dev] Clamato

Dan Ingalls Dan at SqueakLand.org
Fri Sep 4 18:53:30 UTC 2009


Hi, Avi -

>It's easier for me to answer these by listing the major changes and
>how I feel about each of them.

First of all, thanks for your great response.  It's exactly what I had hoped for.  Here are some comments interspersed...

>It's easier for me to answer these by listing the major changes and
>how I feel about each of them.
>
>One change that I am happy with is getting rid of
>#subclass:instanceVariableNames:... style class definitions. A Clamato
>program can be represented entirely as a set of method definitions,
>which is great from a tools perspective. This required a #superclass
>method on the class side (which you override to inherit from anything
>other than Object), and the @ syntax for instance variables.

I agree this is nice.  But why not allow that method to declare some instance variables, et voila.

>I don't love the @ syntax, but it has at least two advantages.  One is
>that, by essentially moving instance variable declarations into the
>methods, you can easily add instance variables to classes in other
>packages - Squeak has never had a good way to do this.  The other is
>that methods can be parsed and compiled with no context - unlike in
>Smalltalk, can identify instance variables vs. temps vs. globals
>without knowing anything about the class you are compiling the method
>for.  OTOH it's kind of ugly.

With all due respect, I agree ;-).

>I *think* I like having left out explicit returns and implicitly
>returning self, in favor of implcitly returning the value of the last
>statement. It unifies methods and blocks in a way I find pleasing.

Definitely worth some points.

>However, my hand was somewhat forced here by Javascript semantics.
>The only way to implement them (that I can think of) would be to throw
>an exception, which would get caught and rethrown at every level up
>the stack frame until it found the right one.  I don't want to do this
>to the poor VM.  I've provided a "self return: [:returnBlock | ...]"
>primitive that provides this when you really need it, but I've found
>it's rarely used.

I need to think about this some more and, more importantly, look at and write some code.  We do a lot of point and rectangle arithmetic which needs returns, as in

	var loc = m.bounds().center().plus(delta)
<==>
	loc = m bounds center addPt: delta

How would you go about this?

...and while we're on the topic of point arithmetic, it drives me nuts that JS won't let you add infix methods.  You can put them in the dictionary, but you can't call them.  What I've thought of is to use St's aggregated infix for non-number users of '+', so 'a + b' translates to  'a + b' for numbers and, eg, 'a &+ b' translates to 'a plus b' for points, dates and the like.

That at least gives us...

	loc = m bounds center &+ delta

I've thought of using '.' for this case, because it is so much less intrusive, as...

	loc = m bounds center .+ delta

>I tried to leave out the cascade syntax, but found it was too useful
>and had to put it back.

I love it!  I've always felt a bit sheepish about cascades, but I put them in because it was a pattern that we found useful in St72 and I wanted to preserve as much as possible of that convenience.

>I dislike not having a proper metaclass hierarchy (class side methods
>don't get inherited by subclasses), but I'm not sure I want to blindly
>copy ST80 here either.  Newspeak has some interesting around
>constructors but they're a tad heavyweight for my taste.

I agree about this.  Haven't missed it at all in the Lively work.  Yes, keep it light.

>Using 0 based indexing keeps tripping me up.  That may go away.

My thinking on that one is to take a deep breath and give up.
Of course I like 1-base better, but there are many more folks in the
world that would be thrown by changing to 1-base, and adoption has
would be nice.  More importantly, and again from my
three years of Lively work is that the more you treat arrays with
high level protocols (forEach, etc) the less it really matters.

>There are currently no array literals.  This is obviously a bad thing,
>I'm just not sure what form they would take.  Allowing JSON literals
>is kinda appealing, and {} isn't doing too much yet.

I agree.

>There's no doesNotUnderstand:, which is a shame, but it's not worth
>the performance hit to allow it.
>
>> What would you still like to change?
>
>I'm very intrigued by Newspeak's "no static state", and the way it
>approaches namespaces.  I haven't felt any pain yet which I would need
>that to resolve, but maybe that will come.

So far I'm pretty happy with our little name space hack that Robert Krahn did, especially since it includes on-demand loading.  [don't know if you've looked at it at all]

>Mostly, though, I'm trying not to get sucked into large-scale language
>design, and instead am looking for the smallest reasonable set of
>changes I can make to Smalltalk that will let it thrive on top of
>Javascript. So if I haven't already needed to make a change to get
>this far, I probably won't make it.

..a point of view I totally respect.

That said, though, are you open to a possible collaboration to put a bit more attention on making it the best it can be without making it significantly more complicated.

I'm still interested in my Lively April Fools prank, and it *could* have huge synergy with what you are doing if we agreed on the language.  You might find that an entire Lively Kernel running in Clamato was a nice reservoir to draw on.

>I'm taking a more radical approach to the tooling.  I really, really
>like the Caesar browser we've developed which treats each type of
>browser (senders, implementor, hierarchy, etc) as simply a search that
>returns a list of methods, and lifts its overall design (tabs +
>location bar + forward/back buttons) from the web browser.  (It's also
>been amazing to work with our web designer, Luke Andrews, on this,
>especially as he's been learning Smalltalk to do it).

I agree that this is cool, and I have great respect for the way you have included folks with decent aesthetics on your team.

Have you integrated this development environment with a repository (haven't gone through your code yet)?  We're very happy with our browser hookup that works with a local version of our repository by live WevDAV hookup.

Ciao
	- Dan



More information about the Squeak-dev mailing list