So the #(static array literals) have been very useful to me due mostly to their compactness.
I recently had a big dictionary of dictionaries of of dictionaries of... and it was convenient to recursively grab the storeString. But if I just #storeString'd it, the string was big enough to make the compiler choke. I ended up recursively sending asArray, and then grabbing static array literals (this was in a Cuis image.) This was a *much* more compact representation of the object in question, and the compiler took to it handily.
At first, I felt the same way that you feel about the static array literals about the dynamic array literals; I didn't have any reference point for the syntax, it looked odd, and reminded me only of dotted pairs in Lisp... which isn't exactly the most recognizable idiom in the world.
Over time, though, the sheer utility of the dynamic arrays changed my mind. I still like having the static arrays for symbolic processing, though.
If you really have a great desire to remove the static array literal syntax, I will offer one piece of advice: find a way to let people have their cake and eat it too. Wouldn't it be cool if our literals could be loaded and unloaded as easily as changing a hat? I think you might even start seeing more experimentation with new literal syntaxen.
It's that old mathematician's trick: if you can find a way to solve the more general problem, you can eliminate a bunch of subproblems in one stroke.
Why not investigate making Squeak's syntax more modular? :)
2011/5/31
info@tomsik.cz <info@tomsik.cz>
What's current state of squeak evolution?
I do get the idea of squeak as independent-smalltalk,
which CAN evolve without being fully compatible with the rest of st world
(which is IMHO the only way to deliver better language)
I've read few dozens of interesting proposals in here
(like prototypes and dropping array literals)
And while both being pretty interesting I would really like
to see smalltalk with [1 . 2 . 3] asArray syntax instead of ugly
and IMHO useless #(1 2 3)
Syntax should be further discussed, yes, at least because [1, 2, 3]
looks much better, but what's the chance of adopting something like this?
What's the chance of saying: "guys, we made mistake, #(1 2 3) have really
no advantage over blocks (except of performance), so let's drop it, let's
simplify the language, let's make it even easier to learn for newcomers."
Is something like this "part of plan"? Or is really the "make a new fork if
you consider it useful" the only way to go?
Because writing meta-program for transforming existing code shouldn't be
so hard. Also "dropping" something could be just part of "changelog", even with
appropriate convertor for legacy code. And I doubt that new fork could make it
through without massive marketing. Even squeak is poorly known.
Please do not take it as offense, ST is one of best languages I've ever encountered,
but every language can be even better, and we should try.
--
Casey Ransberger