Damien Pollet wrote:
> On 04/09/07, Peter William Lount <peter at smalltalk.org> wrote:
>   
>> I agree with Jon that changes to the Smalltalk syntax need to be very
>> carefully considered. The perlification of Smalltalk has already begun
>> unnecessarily with the curly braces!
>>     
>
> I understood "petrification" with the typo in the subject ;)
>
>   
>>     "Same as using curly braces but importantly NO syntax changes needed!"
>>     list := [a. b. c] objects.
>>     
>
> But  a. b. c  is a sequence that evaluates to the result of c. How can
> the block see a and b without doing dirty tricks accessing its own
> source code ?
>
> IMHO curly braces are useful, they replace collection new add add add
> in the same way cascade replaces receiver foo. receiver bar. receiver
> baz. I'd accept message chains if they used the comma but it really
> needs actual usage to proof it's useful.
>
> Now I'd prefer discussions on compile-time expressions, how to extend
> curlies to create arbitrary kinds of collections, and stuff like that.
>
>   
Hi Damien,

Yes! "Petrification" is a nice meaning for "perlification" of Smalltalk. 
The more syntax added to Smalltalk the more rigid and crusty it seems to me.

The curly braces require the same virtual machine statement evaluator 
upgrade as the blocks version does, do it's not any more magic than the 
curly braces are doing! The "objects" (or "values" if you prefer) 
message simply calls an appropriate virtual machine primitive to collect 
up the results of each statement. The normal block evaluator primitive 
results the last result, the new one returns a collection of all the 
results. The primitive for the block version would also optionally allow 
you to provide your own collection of your own choosing to the primitive 
- this provides much more flexibility than the curly braces can hope to 
provide. Also the block version can of course be evaluated at any time 
that you choose.

Curly Braces needlessly have added to the complexity of Smalltalk syntax 
when block can easily do the same job.

Cheers,

Peter