On Thu, Sep 3, 2009 at 9:19 PM, Dan IngallsDan@squeakland.org wrote:
Here's what I project from what I'm hearing...
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.
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.
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
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
On 04.09.2009, at 20:53, Dan Ingalls wrote:
Hi, Avi
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.
Me too! And how well the ";" works with "." to separate statement is amazing. Others are imitating the cascade style by "chaining" but it looks weird and is limited at the same time; see e.g. this message I just got on a Python list:
Begin forwarded message:
it would be awesome to set up chaining so we could do something like
layer['timer'].save().clear(). fillStyle('#fff'). fillRect(10, startTimerY, endTimerX, offsetTimerY). restore();
- Bert -
Bert Freudenberg wrote:
On 04.09.2009, at 20:53, Dan Ingalls wrote:
Me too! And how well the ";" works with "." to separate statement is amazing. Others are imitating the cascade style by "chaining" but it looks weird and is limited at the same time; see e.g. this message I just got on a Python list:
Vasili Bykov gets some very readable statement separation for non-parenthesized chaining of keyword messages, http://blog.3plus4.org/2007/09/ and discussed more fully http://blog.3plus4.org/2007/08/30/message-chains/.
In the context of Clamato, perhaps there is no real reason to tie up "," for string concat (just use "+" for that), and instead use it for parenth-free message chaining including keyword messages?
On Thu, Nov 19, 2009 at 7:50 AM, Sophie424 itsme213@hotmail.com wrote:
Vasili Bykov gets some very readable statement separation for non-parenthesized chaining of keyword messages, http://blog.3plus4.org/2007/09/ and discussed more fully http://blog.3plus4.org/2007/08/30/message-chains/.
In the context of Clamato, perhaps there is no real reason to tie up "," for string concat (just use "+" for that), and instead use it for parenth-free message chaining including keyword messages?
I would be very happy to accept a patch that implemented this.
Avi
squeak-dev@lists.squeakfoundation.org