[squeak-dev] Compiling {} statically?

Eliot Miranda eliot.miranda at gmail.com
Tue Nov 24 17:16:57 UTC 2009


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.

>
> >> Cheers,
> >>  - Andreas
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091124/9fed4822/attachment.htm


More information about the Squeak-dev mailing list