2009/11/24 Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Igor,
>
> On Tue, Nov 24, 2009 at 2:17 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 2009/11/24 Igor Stasenko <siguctua at gmail.com>:
>> > 2009/11/24 Andreas Raab <andreas.raab at gmx.de>:
>> >> Hi -
>> >>
>> >> Here is a question: Does anyone know how much effort it would be to
>> >> compile
>> >> the brace array construct down to a literal array if it only contains
>> >> static
>> >> elements? This would allow us to use {} consistently even in places
>> >> where
>> >> we'd otherwise use #(). I'm not sure if it's worth it but I dislike the
>> >> asymmetry in literal arrays that symbols aren't prefixed by #symbol and
>> >> if
>> >> we'd be able to compile {} statically where that's possible we could
>> >> completely and consistently replace all uses of #() by {}.
>> >>
>> >> Thoughts?
>> >>
>> >
>> > There's one thing, which still different for these two constructs,
>> > even if all elements can be evaluated at compile time.
>> > The {} array is constructed at run time, so one may expect that it is
>> > mutable, while arrays defined using #() not.
>> >
>> > I.e. things like:
>> >
>> > myArray := #(1 3 4 2) sort.
>> >
>> > should lead to error , while
>> >
>> > myArray := {1. 3. 4. 2. } sort.
>> >
>> > not.
>> > From this point, i think compiling {} arrays statically may lead to
>> > unwanted behavior later, when we could have an immutable objects in
>> > Squeak.
>> > But of course, if we leave things as they are (no immutability), then
>> > any literal arrays can be modified, which makes no difference between
>> > those two, except from syntax.
>> >
>>
>> oops.. there still will be difference, because {} arrays constructed
>> each time we run the code,
>>  while #() constructed at compile time. And since Squeak can't offer
>> us the immutability guards,
>> one of the solution may to use {} syntax to ensure that produced array
>> will always have same elements as
>> written in code.
>
> This is a good point but we can cross that bridge later.  When immutability
> is implemented (e.g. at the VM level) we can modify the compiler to either
> revert to the old brace generation code or send an implicit copy, so that {
> 1. 2. 3 } would compile as #(1 2 3) shallowCopy.
> We should quantify.  How many braces expressible as literals are there?
> We should be cautious.  How many braces expressible as literals are actually
> used mutably?  i.e. we're introducing the hidden literal modification bug in
> another form if we do this.
> While its really fun to be able to modify the compiler in less than 5
> minutes to do this I wonder if its worth it in this case.

Its not worth doing, as well, as i think introducing immutability.

myMethod
| array |
array := #(1 2 3).
^ array isMutable ifFalse: [  thisContext method literalAt: 1 put:
array copy ] ifTrue: [ array ]

in system, which is so open, its not worth even trying to introduce
any obstacles, since there can be always a way to bypass them :)

To prevent bypassing by any means, we should redesign the whole system
and build it using a capability-based approach.
This is where NewSpeak and E models come in mind.

The only userful feature of immutability, as to me, is a low-level
assertion mechanism (by analogy to C , when you running a buggy code,
you get a page fault exception - writing to protected memory region).

In practice, this means that it helps to deal with particular class of
errors/bugs, which often is minor ones and in 99% of cases appear at
initial stages of development. But to my experience a most offending
bugs is not those which causing a write-protection exceptions, because
they are much harder to track down & fix :)

And, of course, since we having a stable & running system right before
our eyes without any immutability support, then logical question: how
it was possible to achieve that without immutability? And isn't it
shows how insignificant an immutability is, comparing to other, much
more important stuff, which influencing the system design?


-- 
Best regards,
Igor Stasenko AKA sig.