[squeak-dev] smalltalk evolution

Igor Stasenko siguctua at gmail.com
Tue May 31 13:50:25 UTC 2011


2011/5/31 info at tomsik.cz <info at 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)
>
why useless?
the #(1 2 3) are evaluated at compile time and then stored into
method's literals array.
While anything like
[ 1. 2. 3. ] asArray
will be evaluated at run time.
perhaps you meant another "useless" syntax, which is:
{ 1. 2. 3. }

which is equivalent to:
Array with: 1 with: 2 with: 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?
>

just try to evaluate
1,2,3
in workspace and you will see why this is not good idea.

> 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."
>
[1. 2. 3.]
is not a literal.
it is a sequence of expressions, which should be evaluated when you
send #value to block, and there could be anything like:

[ self foo. self bar. self baz ]

now, how you propose to turn it into array literal?


> 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.
>

Well, i don't think that changing the way how you represent array
literals could drastically change a smalltalk to make it more
appropriate for (put your favorite here).
I think you looking in wrong direction, because what is really makes a
difference is availability of modern and robust solutions and killer
apps, which makes your
language preferable to others.
I don't see how changing the syntax of array literals will make it
easier for appearance a new killer app.

> 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.
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list