<br><br><div><span class="gmail_quote">On 9/5/07, <b class="gmail_sendername">Peter William Lount</b> <<a href="mailto:peter@smalltalk.org">peter@smalltalk.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>A special category of exceptions to library only extensions exist that<br>enable the opening of a new dimension of capability. For example, blocks<br>enable anyone to create new control flow structures in Smalltalk. It's
<br>still surprising how people are continuously innovating in with methods<br>for blocks and unique ways of using them. I look for opportunities to<br>enhance a language syntax that create these new dimensions. I see the
<br>gap of possibilities and a few innovative ways of using it but it's how<br>big the gap is that's key.<br><br>The curly braces don't create a new dimension of possibility beyond the<br>few uses since the the curly braces are not extensible in the class
<br>libraries.</blockquote><div><br>I just thought up an alternative to curly braces that doesn't change the compiler. I chose an unused operator and implemented it so that:<br><br>'hello' ++ 'world' ++ 1
<br>returns an OrderedCollection('hello' 'world' 1) "actual result from my 3.10 image"<br><br>You could do the same with a list of Associations to make a Dictionary. If it is slow, then you could modify the Compiler to optimise for this operator, but it wouldn't need changes to the syntax of the language.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, the block version of continuously collecting<br>statement evaluations does enable a new dimension. I don't know all the
<br>uses. But already in this discussion someone found one, by adding a<br>third evaluator for concurrency purposes. That's not just another use<br>but an entire other dimension found! Now to implement them and extend
<br>the power of blocks into the future.</blockquote><div><br>For your specific example of concurrency, I'd much rather do something like this:<br><br>( [ s1 doSomething ]<br> ++ [s2 doSomething]<br> ++ [s3 doSomething]
<br>) doConcurrently.<br><br>(aka: implement OrderedCollection>>doConcurrently)<br><br>This pattern might have implementation possibilities such as waiting until all processes have finished before continuing, or using a set of worker threads rather than making new threads.
<br><br>What I'd really like to see is a concurrent Collection of some sort, where methods such as do: have multi-threaded implementations.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Other languages are catching up and surpassing Smalltalk - we need to<br>keep up and jet to the future.<br></blockquote></div><br>Have you seen Java recently? I'd hardly call the latest language changes "progress".
<br><br>IMO what Smalltalk / Squeak really needs to be competitive in the future is the ability to make full use of the latest batch of multi-cored processors. This can be done using libraries and VM modifications rather than changing the language.
<br><br>Michael.<br>