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