Compiling {} statically?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling {} statically?

Andreas.Raab
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?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

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

> Cheers,
>  - Andreas


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

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

>> Cheers,
>>  - Andreas
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

Bert Freudenberg
In reply to this post by Andreas.Raab
On 24.11.2009, at 10:51, Andreas Raab wrote:
>
> 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?

Well you can actually #symbol notation in #() too. It's just optional.

OTOH I have seen newbies use {} exclusively, apparently unaware of #(). It's an odd construct for sure. Just too convenient to kick out.

But I don't think changing the semantics of {} is a good idea. It is just syntactic sugar for array construction at runtime. Or would you suggest to compile "Array with: 42" statically too? ;)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

Stéphane Rollandin
>
> OTOH I have seen newbies use {} exclusively, apparently unaware of #(). It's an odd construct for sure. Just too convenient to kick out.

and it allows nice tricks:

prog := #(funcall (lambda (x) (sqrt x)) 5) asCons

in
http://www.zogotounga.net/comp/squeak/lispkit.htm


Stef



Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

Casey Ransberger
<2cents>

It's great having a late binding list construct, but I must admit: I
don't like the syntax very much, and typing the periods bugs me when I
don't need to. I'd like to keep #() for that reason, and for
compatibility with other dialects.

</2cents>

2009/11/24 Stéphane Rollandin <[hidden email]>:

>>
>> OTOH I have seen newbies use {} exclusively, apparently unaware of #().
>> It's an odd construct for sure. Just too convenient to kick out.
>
> and it allows nice tricks:
>
> prog := #(funcall (lambda (x) (sqrt x)) 5) asCons
>
> in
> http://www.zogotounga.net/comp/squeak/lispkit.htm
>
>
> Stef
>
>
>
>



--
Ron

Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

Eliot Miranda-2
In reply to this post by Andreas.Raab
Hi Andreas,

    good point.  This is something that Gilad does in Newspeak.  Find attached.  After this change the doit

{ 1. '2'. #3 } -> {1+1. 1+2}.
thisContext method literals

answers

#(#-> #(1 '2' 3) #literals #method #DoIt #UndefinedObject)

Beware, this has undergone almost no testing ;)

On Tue, Nov 24, 2009 at 1:51 AM, Andreas Raab <[hidden email]> wrote:
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?

Cheers,
 - Andreas





LiteralBraces.st (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compiling {} statically?

Eliot Miranda-2
In reply to this post by Igor Stasenko
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.

>> Cheers,
>>  - Andreas
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.