Back to immutability [Was: Re: Compiling {} statically? ]

> Hi Igor,
>
> On Tue, Nov 24, 2009 at 2:17 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2009/11/24 Igor Stasenko <[hidden email]>:
>> > 2009/11/24 Andreas Raab <[hidden email]>:
>> >> 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.