Extending Smalltalk Syntax
In the comments to this post, a discussion about extending the syntax of Smalltalk came up. In particular, Rich liked the F-Script array extensions. Peter William Lount has a nice write up on that here.
Here's the thing - in this case (and in most of the things that come up), we don't actually need to change the syntax of Smalltalk. You want to be able to replace:
someCollection collect: [:each | each name]
with this:
someCollection name
Well, all you need to do is add this method to class Collection:
doesNotUnderstand: aMessage | selector | selector := aMessage selector. ^[self collect: [:each | each perform: selector]] on: MessageNotUnderstood do: [:ex | self]
Now, if I do this simple test:
people := OrderedCollection new. people add: (Person new firstname: 'fred'; lastname: 'flintstone'). people add: (Person new firstname: 'barney'; lastname: 'rubble'). people add: (Person new firstname: 'wilma'; lastname: 'flintstone'). people add: (Person new firstname: 'betty'; lastname: 'rubble'). people firstname.
Then you end up with a collection of the firstnames. Now, there are some obvious issues with this new approach:
- I can't send messages through if the collection itself understands them (say Person understood #first instead of #firstname, for instance)
- What if I would rather have the protocol use #select: instead of #collect:
Either way, if this sort of thing is something you want, you can do it yourself without having to modify the syntax of the language. Which is good - because you can also change it easily if you don't like it. Syntax changes are just there, and you have to deal with them whether you like them or not. Which is why the approach taken by Java and C# sucks so much...
Comments
Re: Extending Smalltalk Syntax
[ Rich Demers] September 20, 2004 21:58:54.194
Comment on Extending Smalltalk Syntax by Rich Demers
Jim,
What you say here is true, but still misses the point. Anyone can implement your #doesNotUnderstand: approach to apply a message to the members of an array, but the point made by F-Script is that only a small number of syntax changes are needed to go way beyond this, to implement powerful message patterns. These message patterns enable the full range of object behaviors to be applied to the members of arrays and to operations between two arrays, and they allow the use of powerful operators (a new concept to Smalltalk: compression, reduction, inner and outer product, etc.).
I don't disagree that hacking a language's syntax to add discrete, seldom used new features is a bad idea, but I also believe that the Smalltalk community should seriously consider minor syntax changes that enable large-scale semantics changes that are orthogonal to the the basic semantics of the language. I see the F-Script proposal in this later light.
In other words, I don't agree that all syntax changes are unnecessary and inherently wrong.
An issue we should also be discussing is HOW to go about deciding how Smalltalk should evolve -- for evolve it must. Too many good ideas get put forward only to be lost in the great bit-bucket of the Internet. There should at least be a way to record them in a central repository of possible changes, and a way subsequently evaluate them and discuss them for recommendation to the Smalltalk vendors.
Extending Smalltalk Syntax
[ James Robertson] September 21, 2004 0:09:57.865
Comment by James Robertson
Rich,
You make my point. You say:
The trouble with adding syntax "to extend the power of the language" is that you often end up doing the opposite. You add a few reserved words that are now locked in and unusable by anyone for any other reason. The advantage of the approach I sketched is that it's malleable. Adding syntax is rigid. Having looked over what the F-Script guys did, I don't really think it's worth it - it bakes in stuff that I would much rather see added on a project basis for domain specific reasons.
Do you have a better example?
I agree with James ...
[James Ladd] September 21, 2004 1:36:57.577
I have to agree with James. Adding reserved/keywords to a language should be avoided if possible. Smalltalk is awesome in that you can do a great deal without introducing new language syntax.
Why do the F-Script array extensions have to be added to the language as apposed to being supported by protocol ?
Michael Lucas-Smith
[Michael Lucas-Smith] September 21, 2004 6:58:21.776
Hey, why not load up HigherOrderMessaging from PublicStore, then you can write the following (for real):
someCollection collect name
Michael Lucas-Smith
[Michael Lucas-Smith] September 21, 2004 7:49:50.673
Heck, you can even do better: (someCollection select age > 16) collect name reverse do inspect
not so simple
[verbat] September 21, 2004 8:50:50.825
F-Script array integration is more wide then this simple sample, both in syntax (just to say, you can have array @message: args or array message:@ args )
But the core point is a change in how problems are handled, the same way that having objects is different from just having closures.
Extending Smalltalk Syntax
[ Rich Demers] September 21, 2004 9:18:49.057
Comment by Rich Demers
Jim,
I did not make your point; you simply ignored mine, that F-Script's message patterns enable the full range of object behaviors to be applied to the members of arrays and to operations between two arrays, and they allow the use of powerful operators.
These are tremendously powerful ideas that go far beyond the simple examples you and Michael keep repeating.
I am NOT advocating change for change's sake, nor am I advocating gratuitous complexities for minor returns. But we should be open to truly powerful ideas that would greatly enhance the language at low cost. I view these F-Script enhancements in this light.
Extending Smalltalk with Smalltalk.org
[Peter William Lount] September 21, 2004 12:52:44.844
Rich Demers wrote: "An issue we should also be discussing is HOW to go about deciding how Smalltalk should evolve -- for evolve it must. Too many good ideas get put forward only to be lost in the great bit-bucket of the Internet. There should at least be a way to record them in a central repository of possible changes, and a way subsequently evaluate them and discuss them for recommendation to the Smalltalk vendors.
Smalltalk.org is prepared to be a clearing house for existing and proposed enhancements to Smalltalk. One central place for all the materials on this important topic. Smalltalk.org is a central place that's willing to collect the possible changes and host the discussions. Send in your proporsals, comments, desired objectives, goals and outcomes.
Please see Extending Smalltalk.
Extending Smalltalk Syntax
[ Reinout Heeck] September 23, 2004 10:28:45.098
Comment by Reinout Heeck
Smalltalk.org is prepared to be a clearing house for existing and proposed enhancements to Smalltalk.
Great, but I would like a wiki with it to be useful, else I wouldn't feel much like contributing (and more importantly: refining).
A wiki an article or digest series sounds like a really great way of handling these 'eternal' discussions that IMO do need resolution.
So please hook this article series up with a wiki!
Extending Smalltalk Syntax
[ Reinout Heeck] September 23, 2004 10:44:44.409
Comment by Reinout Heeck
Rich
you are aware that you can override #compilerClass and #classCompilerClass on your classes?
This way you can safely play with F-Script language experiments in selected hierarchies. I found the SmaCC parser generator to make it quite easy to do this kind of experiments (like for example embedding a wiki in the IDE (and hence in Store) rather than in a web server).
HTH
Extending Smalltalk Syntax
[ Rich Demers] September 23, 2004 12:34:09.189
Comment by Rich Demers
Reinout,
Yes, I am aware that I can override the compiler to try whatever I want in Smalltalk. But that's not the issue here.
The issue is whether any changes to the syntax or semantics of Smalltalk should ever be considered by the Smalltalk community. I fully realize that this is a "try it and show me" culture, but we can't all try everything. Right now, I don't have the time to do what you suggest with F-Script -- as much as I would like to. Does this mean I shouldn't look at what someone else has done, evaluate it against my own experiences with Smalltalk and other languages, and then state a reasoned position? I hope not, because then no one's ideas would ever get a fair shot.
Because of my experience with APL, I believe that F-Script deserves a thorough evaluation by the Smalltalk community. At the least, it shouldn't be dismissed out-of hand because of anyone's preconceived notions about the "perfection" of Smalltalk's syntax.
Extending Smalltalk Syntax
[ James Robertson] September 23, 2004 12:40:39.798
Comment by James Robertson
Rich You misunderstand my objection. I don't think Smalltalk syntax is "perfect" - but I also don't think that grafting on new syntax to add "power" as each fad jogs by is a great idea either. One of Smalltalk's great strengths, IMHO, is that the syntax hasn't changed much in 30 years - people have been able to implement things (like Higher Order Messaging, Continuations, etc) without kludging the syntax up. Let the Java and C# people explore the "power through additional syntactical rules" road.
snakeoil
[Robert Collins] September 26, 2004 22:18:57.092
The F-Script paper differentiates operations on objects (i.e. X+Y; X,Y E Integers), and operations on Arrays (i.e. X+Y; X,Y E Array).
Maybe I'm missing something but this ignores the primary goal of OOP - Arrays can be given the operator +, so X+Y becomes valid, and does what you'd expect. Likewise for *, (though in smalltalk that would be dimension: IMO, / etc.
For the argument against doing this - pg 3 (Extensability), it sounds like the 'typical' way is arse-backwards. I.e. teaching + to understand arrays is wrong: you teach arrays to understand that + is different. Doing this in the class library is more flexible than doing the same in the syntax.
So, while there may be great value in it, the argument that you get 'higher level operators' is IMO snakeoil: you can experiment with, and get such higher level operators with the current unary, binary and keyword message.
Re: snakeoil
[Philippe Mougin] October 3, 2004 12:14:59.707
Robert,
The problem with the approach you describe is that when you add a method to a class, you also have to add one (or more) dispatching method to the "Array" class in order to be able to manipulate instances of your class in an array programming way. Smalltalk allows you to do that, and it's great for experimenting things. However, the F-Script approach is much better since you don't have to write any additional code.
Your approach is like saying to someone that is showing you an object-oriented language that he's missing the point because you can have dynamic binding in your non object language by manually adding dispatch code for each of your functions inside a giant "switch" statement.
In an array programming language, by definition, we don't want to have to write the dispatching code that iterates over collections. This is why nobody considers Smalltalk to be an array programming language. The point of the F-Script paper is to bring array programming to OOP, and in particular to Smalltalk.