Now as I implemented it, I think I should sort-of try to defend the idea.
Actually, I'm surpised that everybody seems to dislike the idea.

>What about #at:ifAbsent:, #at:ifPresent:, #at:ifAbsent:ifPresent:,
>#at:put:ifAbsent:, #at:put:ifPresent:, #at:put:ifAbsent:ifPresent:? 

If "alternative" means "replacement", I picked the wrong term.  Both syntax
forms "[]" and "[]:=" were meant as an extension to the normal message send
expression form, just for the convenience of easier reading.

>As you add shortcuts "[ ]", binary
>selectors "&!@$*<>~", and other "features" you clutter the simple and
>consistent message sending model of Smalltalk.

I'm afraid, simple doesn't always mean easy to use or easy to learn.
Familiarity is much more important for this, I think.  I'd like to quote
Larry Wall in this context, who (I think) always argued that a language
should provide more than just one way to do things, but I don't remember
the exact words. Interestingly, languages with "simple" grammars like i.e.
Lisp always had acceptance problems.

I agree, that a language shouldn't be too cryptic. It's not about coding,
it's about writing programs.  I really like this argument.

>An old quote:
>"Just because you can do a thing does not mean that you do the thing".

Well, I'm afraid, the explorations of borders - and beyond - is just too
human :-)

>What does "a[12]" generate? "a at: 12"? How would I know
>which method to lookup in a class? Or wouldn't it be better to take all of
>the shortcuts like "a[12]" and treat them like a macro that gets processed
>into actual source and then compiled? That way you can have as many of your
>shortcuts as you like but all of others could just read the macro processed
>source code with expanded method selectors!

If you install my code, then you'll see that this is exact the way it's
done. (Just add pretty printing and the macros are gone - unfortunately, PP
seems to decompile instead of just formatting)  Actually, I'd love to
generalize this kind of macro expansion.

>There could be confusion with blocks with "[12]" or "[index]"!

In the same way as you could confuse variables with message selectors, yes.


bye
--
Stefan Matthias Aust  //  ...and now something completely different