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 |
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. |
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. |
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 - |
>
> 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 |
<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 |
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)
On Tue, Nov 24, 2009 at 1:51 AM, Andreas Raab <[hidden email]> wrote: Hi - LiteralBraces.st (3K) Download Attachment |
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]>: 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.
|
Free forum by Nabble | Edit this page |