So the #(static array literals) have been very useful to me due mostly to their compactness. <div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Over time, though, the sheer utility of the dynamic arrays changed my mind. I still like having the static arrays for symbolic processing, though. </div><div><br></div><div>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. </div>
<div><br></div><div>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. </div><div><br></div><div>Why not investigate making Squeak's syntax more modular? :)<br>
<br><div class="gmail_quote">2011/5/31 <a href="mailto:info@tomsik.cz">info@tomsik.cz</a> <span dir="ltr"><<a href="mailto:info@tomsik.cz">info@tomsik.cz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What's current state of squeak evolution?<br>
<br>
I do get the idea of squeak as independent-smalltalk,<br>
which CAN evolve without being fully compatible with the rest of st world<br>
(which is IMHO the only way to deliver better language)<br>
<br>
I've read few dozens of interesting proposals in here<br>
(like prototypes and dropping array literals)<br>
<br>
And while both being pretty interesting I would really like<br>
to see smalltalk with [1 . 2 . 3] asArray syntax instead of ugly<br>
and IMHO useless #(1 2 3)<br>
<br>
Syntax should be further discussed, yes, at least because [1, 2, 3]<br>
looks much better, but what's the chance of adopting something like this?<br>
<br>
What's the chance of saying: "guys, we made mistake, #(1 2 3) have really<br>
no advantage over blocks (except of performance), so let's drop it, let's<br>
simplify the language, let's make it even easier to learn for newcomers."<br>
<br>
Is something like this "part of plan"? Or is really the "make a new fork if<br>
you consider it useful" the only way to go?<br>
<br>
Because writing meta-program for transforming existing code shouldn't be<br>
so hard. Also "dropping" something could be just part of "changelog", even with<br>
appropriate convertor for legacy code. And I doubt that new fork could make it<br>
through without massive marketing. Even squeak is poorly known.<br>
<br>
Please do not take it as offense, ST is one of best languages I've ever encountered,<br>
but every language can be even better, and we should try.<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>