--- Roger Vossler <rvossler at 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:
> 
> 1) 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.

> 2) 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.

> 3) Do most other Smalltalk systems have this capability?

Yes.

> 4) 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.

> 5) 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