[squeak-dev] Clamato

Avi Bryant avi at dabbledb.com
Fri Sep 4 05:42:59 UTC 2009


On Thu, Sep 3, 2009 at 9:19 PM, Dan Ingalls<Dan at squeakland.org> wrote:

> Here's what I project from what I'm hearing...
>
> 1.  You like Smalltalk, so you want a language that is as much like it as possible... except for things you don't like, of course.  This also fits in with your "shop" that does a lot of other real Smalltalk work.
>
> 2.  You want to take advantage of engines like V8 that offer (a) ubiquity in browsers, and (b) escalating performance paid for by the few remaining profitable companies.
>
> 3.  This implies a very close mapping onto JavaScript semantics, but really only onto the subset that you need for the job.

Dead on.

> What have you left out on purpose because you don't like it?
> What have you left out that you would rather not leave out?
> What have you changed that you would rather not?

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

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.
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 tried to leave out the cascade syntax, but found it was too useful
and had to put it back.

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.

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

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.

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.

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.

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

Avi



More information about the Squeak-dev mailing list