--- Roger Vossler rvossler@qwest.net wrote:
I read the material concerning Block Closures (BC) on the GaTech web site, but it's a bit beyond my meager understanding.
Sorry it is just technical, hopefully the answers below will help. Others may want to add to my answers.
I have a couple of questions:
- Why is BC so important?
BC speeds up the Interpreter and correctly interprets the scopes of blocks. To elaborate on the second point: Blocks holding their own temps (block closures) is more correct from a scoping point of view than method contexts holding the temps for its embedded blocks (current Squeak). For example: #(a b c) do: [:s | [Transcript show: s] fork] will print 'abc' in the BC version but 'ccc' in the current Squeak version. The BC version is correctly scoped because the block variable s has a different binding on each iteration. However, in the current Squeak version the block variable s has only one binding held in the home method context and just changes value on each iteration. By the time the forked blocks are executed s is holding the last value.
- What does one gain from this capability?
You gain correctly scoped blocks, which allows you to more easily create truely independent functions/blocks. Sometimes this is preferred over creating special small "function" objects or using additional methods just so you have another scope to bind temps to. For examples of sophisticated uses of blocks that would not work in the current Squeak implementation unless they were rewritten using more methods/classes, see the block closure test cases in the BC image or on the BC swiki page in the Convert section.
- Do most other Smalltalk systems have this capability?
Yes.
- Is this capability "nice to have" or is it "really essential"?
It is not essential since code like the example above can be rewritten to use an intermediate method to provide the missing scope. For example, the following will work correctly in the current Squeak implementation: UndefinedObject compile: 'forkWriting: s [Transcript show: s] fork'. #(a b c) do: [:s | self forkWriting: s] BC just makes it much easier to make these blocks independently scoped.
- If BC is "really essential", how has Squeak managed to get along
without it thus far?
Block closure is not essential as noted above. But it does force people to sometimes write code the long way like the example above.
I'm not looking for detailed technical information, but rather, an indication of why the Squeak community needs to make this change which apparently has big impacts on image formats, VMs, et al. As someone noted: we don't want to do this more than once.
Two main reasons why Squeak needs BC are: 1. Block closures conform to the scoping rules of [...] (BC is more correct). 2. This BC implementation is faster. Since the interpreter had to be changed anyway to accomodate block closures I took the opportunity to make further changes to speed up the whole interpreting process. Either of these may be important enough, but together, I think they (plus possibly other VI4 enhancements) makes it worth the pain to switch the community to a new image format.
Of course, we can make the switch as painless as possible by providing the image converter with the new VM and have the new VM trigger the converter when it tries to open an old image. The major problem is that image conversion takes a long time (about an hour on a 3.2 image on my 533MHz Intel). Also trying to open a new image with an old VM will just report a bad format message.
Cheers, Anthony
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com