Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Tue Sep 4 23:09:23 UTC 2007


Bert Freudenberg wrote:
>
> On Sep 4, 2007, at 12:42 , 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 ?
>
> "[a. b. c]" is just a block defining a sequence of statements. The 
> value depends on how you evaluate that block - sending #value only 
> retains the last value, but you could as well define another 
> evaluation strategy by sending another message.
>
> One could even define new semantics instead of a sequence:
>
>     [a. b. c] valueConcurrently
>
> could mean to evaluate each statement concurrently.
>
> - Bert -
>
>
>
>
Hi Bert,

That's excellent Bert! With all the multicore chips out these days that 
could be useful for the parallel programming paradigm (assuming that the 
Smalltalk in question uses native threads to take advantage of those 
cores). The tile64 chip has 64 cores and squeak will run on it with a 
minimal port (linux, 32 bit, C compiler accepted).

Yes, "[a. b. c] value" returns one value, c, while "[a. b. c] values" 
(or objects) returns three values in a collection. One could imagine 
#valuesInArray, #valuesInOrderedCollection, #valuesInSet, #valuesIn: 
aCollection, #valuesToStream:, etc...

Cheers,

Peter





More information about the Squeak-dev mailing list