Example from my previous reply to Randal for illustration:
Point new: [x: 3, y: 4, printOn: aStream].
Always left-to-right syntax, always one argument, possible multiple receivers and messages, syntax sugar for closures, closure always have only one argument which is also implicit receiver - you can't deny it's at least interesting to think about such kind of uniformity.
Example : / for building file path
okay, maybe, still not worth of losing left-to-right
2.) keyword messages with more than 2 arguments are just ugly - they smell in the "missing another object" way. And 2 arguments are rare too. Iwould allow one argument at top.
They are rare anyway... In my experience, the 16 arguments limit, though well founded from Object POV, is limiting interoperability with 3rd party library (LAPACK) and that's just boring. My opinion is that educating is better than just forbiding. We can tolerate exceptions. Anyway, the workarounds we'll build might well be much uglier...
dic := Dictionary new. SystemNavigation default allBehaviorsDo: [:e | e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: s]]. dic collect: [:e | e size] -> a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88 7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 )
yes, however I think external libraries shouldn't be just "bridged", new library should be designed, in the mood of rest of the language.
3.) unary messages - I would drop them too, and the reason is - I don't write a lot of "return" code, I give orders, I want actions from my objects. I don't want another objects on which I can operate (or get another ones, and again and again). But another syntax sugar for passing "yourself" would be needed :-/.
4.) all of this could result in consistent syntax like: receiver doSomething: yourself. receiver doSomething: param.
I'm not convinced it would ease readability. OK, imperative shall be the preferred mode, tell don't ask, but eliminating queries altogether is a bit totalitarian to my taste. I invite you to rewrite a utility library, say Graphics, with this style and come back with the result if you are pleased with it.
Have a look on that illustration on top - imperative while still readable: create new point, with x: 3, y: 4 and print it on given stream.
this simplification also allows like-english cascade: receiver doSomething: param, doSomethingElse: anotherParam.
or multiple receivers (like F-Script): receiver, anotherReceiver, anotherReceiver doSomething: yourself, doSomethingElse: param.
This is not proposal, just my current "state-of-thinking".
Designing a language is a very interesting topic. But a very involved one too. I'd say try it, eat your own dog food and share a posteriori opinions, it will be much more fruitfull.
Nicolas
I think about it - I was just curious about: 1. if there is any effort to change squeak on language level 2. what do people who already implemented one successful language, think about what I've just written
Kamil